2、cookie，也不建议存放 datatable 这样的“大数据”。因为 cookie 不仅有 4k 上限，并且不是
“纯存放在客户端”这么简单，要知道 cookie 的值在每次 web 页面请求往返的过程中都是要
附带在

http 头中的，如果太大会占用服务器和客户端之间的网络带宽（虽然只是 4k，但在

线人多

 了可就是 4k * n 了）。对于 b/s 结构的应用来说，网络带宽是性能最主要的瓶颈之一！

另外，对于

datatbale 转换成 json 字符串再存入 cookie，服务器 CPU 也会消耗。最可怕的是，

一但你的

cookie 忘记删除了，那么在其有效期和作用域内，用户访问你的所有页面时都将

携带这个

4K 大小的 http 头，那就悲剧了。10000 在线人数，4 千兆网卡也不够你花的。

   3、数据库连接，每次保存查询语句然后再查询的方式不错，不过看你的查询复杂度了，
如果很费时的查询，这样调用也是不可取的。内存和

cpu 的矛盾你要根据 实际情况作出选

择。对于具有连接池的应用来说，一次连接数据的成本并不高，经过测试差不多

=10 次调用

取当前系统时间函数。但查询语句的复杂度就没谱了。

 另外，如果并发人数很多的情况下，

频繁占用数据库连接，会导致连接池没有可用连接了，那就又悲剧了。此时就不是一次连接
的成本，系统整体性能将毁灭性的下

 降，反应迟钝。

    4、cache：一个不错的选择，不过它可同样是占用服务器内存哦，只是比 session 多了一
些灵活性。不过我也不建议你用于存放传递参数的地方。要知

 道 session 就算内存满了也不会

丢失你的参数值（会抛异常），可

cache 可不是，它会直接删掉你的参数值，甚至内存极

度不足时都不会让你进去（也不

 会报错）。换句话说，可能上一行代码刚存进去，下一行

代码去读就丢了。很可怕吧

~

    5、form 表单：最为提倡的方式，http 协议中原本页面间传值的方法就是这样的，只是有
时不太方便，能用之则用之。
    6、自定义存储机制：如果你对性能要求很苛刻，或者非要精益求精的话。那么还是自己写
一个存储机制吧。例如我自己就是写了自己的

XSession 对象，它 的用法与 session 使用类似，

但是存储机制都是我自己封装的，既有

cache 的优点、又有 session 的优点，还有数据库的优

点、性能看你写的算法

 了、而且具有更大的使用灵活性。缺点就是需要你自己 coding...