今天跟一个做电商的朋友聊天，他吐槽说后台有个表单，客户填完信息死活提交不上去。我一看代码，好家伙，那个输入框被设成了 readonly，连光标都进不去，但他又没加 disabled。这哥们儿还觉得挺得意，说这样既不让改，又能保留值，多完美。我差点没忍住笑出声。

在 c 网站开发 的圈子里，这种小细节最容易翻车。readonly 和 disabled 看着像双胞胎，其实脾气差远了。很多人搞混，导致前端体验极差，后端数据还收不到。咱们今天不扯那些虚头巴脑的理论，就聊聊我在这一行摸爬滚打七年，踩过的坑和总结出来的土办法。

先说 readonly。这玩意儿就像是你把车钥匙插进去，但把方向盘锁死了。用户能看到里面写了啥，也能复制粘贴，但就是改不了。这在展示用户信息、或者某些固定配置项的时候，挺好用。比如用户注册后，显示他的用户名，你肯定不想让他随便改，这时候用 readonly 就很合适。

但是，千万别把它当成 disabled 的替代品。disabled 是什么？是彻底废了。按钮变灰，点击无效，最要命的是，当表单提交的时候，disabled 的字段根本不会发给服务器。这就很尴尬了，你以为用户填了，其实后端收到的是 null 或者空值。

我见过太多新手，为了省事，把所有不想让用户改的输入框都设成 disabled。结果前端看着挺正常，后端一查日志，数据缺失，排查半天才发现是这个问题。这就是典型的“看起来没问题，用起来全是雷”。

那什么时候该用 readonly 呢？我觉得得看场景。如果你希望用户能看到数据，甚至能复制数据去别的地方用，但又不允许修改，那就用 readonly。比如订单详情里的“订单编号”，用户可能需要复制这个编号去联系客服，这时候 readonly 就是最佳选择。它保留了交互的完整性，用户还能聚焦、还能选中文本。

再说说 c 网站开发 中常见的坑。有些时候，我们需要动态切换输入框的状态。比如，用户点击“编辑”按钮，readonly 消失，变成可编辑状态；点击“保存”，又变回 readonly。这时候，用 JavaScript 动态切换属性是最稳妥的。别想着用 CSS 去隐藏或者禁用，那都是耍流氓，屏幕阅读器可不管你那套，无障碍访问直接瘫痪。

还有一点，很多人忽略了表单验证。用了 readonly 之后，前端验证逻辑可能还会去校验这个字段。如果后端逻辑依赖这个字段的存在，而前端又没处理好，很容易出现数据不一致。我在做一个会员管理系统时，就遇到过这种情况。会员等级是只读的，但前端为了美观，加了个假的下拉框，结果提交的时候，把下拉框的值传上去了，跟数据库里的真实等级对不上。最后查了两个小时 bug，才发现是前端逻辑和后端预期不一致。

所以，做 c 网站开发 的时候，一定要清楚每个属性的语义。readonly 是“只读”，不是“禁用”。它允许聚焦，允许复制，允许通过键盘操作（虽然不能修改），最重要的是，它允许数据随表单提交。这一点，比 disabled 强太多了。

当然，也不是说 readonly 就完美无缺。它有个小毛病，就是样式上有时候不太好控制。不同浏览器对 readonly 的默认样式处理不一样，有的会有个淡淡的灰色背景，有的则没什么区别。这时候，就得靠 CSS 去微调了。别指望它自动适配所有主题，手动加个 class 控制一下，心里才踏实。

最后，给各位同行提个醒。别为了炫技或者偷懒，滥用这些属性。每一个属性背后，都代表着一种交互逻辑。你要站在用户的角度想想，他看到这个框，心里是怎么想的？是想看，还是想改？是想复制，还是想忽略？想清楚了，再决定用 readonly 还是 disabled，还是干脆换个 display:none。

技术这东西，说到底就是为人服务的。代码写得再漂亮，用户用得别扭，那也是白搭。我在这一行干了七年，见过太多因为一个小属性没选对，导致整个项目返工的情况。所以，别嫌麻烦，多测试，多模拟真实场景。

如果你还在纠结某个字段到底该用哪种状态，或者在 c 网站开发 过程中遇到了类似的表单交互问题，欢迎随时找我聊聊。咱们一起把用户体验做好，毕竟，口碑才是咱们这行的硬通货。别等到客户投诉了，才想起来改代码，那时候黄花菜都凉了。