---

一、开局先问：你传的参数被"劫持"过吗？

举个真实案例：老王开发了个会员系统，用URL传用户ID（像这样：user.jsp?id=1001）。结果被用户发现改个数字就能看到别人的信息，你说尴尬不尴尬？这时候就该思考——??什么时候该用Session藏数据，什么时候能用URL显摆参数??？

---

二、参数界的"显眼包"和"隐身侠"

??URL传参??就像把秘密写在明信片上：

• 优点：简单直接，复制链接就能重现结果
• 缺点：参数暴露在地址栏，长度限制2083个字符

??Session传参??好比用保险箱传递机密：

• 优点：数据存在服务器端，能存复杂对象
• 缺点：占用服务器内存，需要及时清理

举个栗子：用户登录信息用Session存，商品ID用URL传。就像你不会把银行卡密码贴脑门上，但可以让别人看到你买了啥商品对吧？

---

三、选择困难症急救指南（对照表）

场景特征	推荐方案	具体案例	踩坑预警
敏感数据传递	?? Session	用户手机号、支付金额	URL参数会被浏览器记录
需要持久化存储	?? Session	购物车商品保持30分钟	要设置超时时间
需要分享页面状态	?? URL传参	商品筛选条件链接	别传超过500字符
临时单次传递	?? URL传参	页面跳转时的分类ID	记得做URL编码

---

四、Session的正确打开方式

??新手容易犯的错??：把整个用户对象往Session里一扔就不管了。有次我接手个项目，Session里存了10MB的图片base64数据，服务器内存直接爆炸！

??正确姿势??：

1. 只存必要字段（比如userID而不是整个User对象）
2. 用完马上移除：session.removeAttribute("tempData")
3. 统一命名规范：模块名_用途（如"order_paymentAmount"）

??特殊技巧??：用监听器控制Session生命周期，像这样设置30分钟自动销毁：

java复制
session.setMaxInactiveInterval(1800); // 单位是秒

---

五、URL传参的三大军规

1. ??加密敏感参数??：别直接传userID=123，改用加密后的token

   • 错误示范：/resetPassword?username=admin
   • 正确做法：/resetPassword?token=7a8sd76f8a7s6df

2. ??长度控制诀窍??：用缩写代替长参数名

   • 把productCategory=electronics简写成cat=elec

3. ??防御特殊字符??：一定要用URLEncoder处理

   • 错误代码：
   • 正确姿势：<%=URLEncoder.encode(kw,"UTF-8")%>

---

六、一个让我栽跟头的真实事故

去年双十一，我们的优惠券系统用URL传参发券。结果用户把链接里的couponValue=100改成1000，竟然成功使用了！后来改成用Session存储校验码才解决。

??教训总结??：

• 重要参数必须做二次验证
• 不要相信客户端传来的任何数据
• 金额类参数永远用Session+数据库校验

---

七、个人观点时间

说实话，我现在更偏爱Session方案。但千万别走极端——见过有开发者连页面跳转都要用Session传参，搞得像在用Session谈恋爱似的难舍难分。

记住这个原则：??像保护密码一样保护Session，像写日记一样谨慎使用URL参数??。刚开始可能会觉得麻烦，等你的系统被攻击过，就知道这些规矩都是前辈们用血泪换来的经验了。