只读与禁用区别详解

从现在开始，我们要努力学习啦！今天我给大家带来《Input只读与禁用区别详解》，感兴趣的朋友请继续看下去吧！下文中的内容我们主要会涉及到等等知识点，如果在阅读本文过程中有遇到不清楚的地方，欢迎留言呀！我们一起讨论，一起学习！

Readonly字段不可编辑但可选中复制且随表单提交，disabled字段完全禁用且不提交。1.readonly阻止用户手动修改，但允许通过JavaScript修改值，适用于展示需提交的固定信息；2.disabled禁止所有交互且数据不提交，适用于临时禁用或无需传递数据的场景；3.从用户体验看，readonly表示内容只读，disabled表示功能不可用；4.后端可通过表单接收readonly字段值，但无法直接获取disabled字段数据；5.JavaScript可动态操作两者属性，但readonly侧重值管理，disabled侧重状态控制与事件阻断。

readonly 属性让输入框内容不可编辑，但用户仍可选中、复制，并且内容会随表单一起提交。而 disabled 属性则完全禁用输入框，不仅不可编辑，内容也不会被提交，且通常在视觉上呈现为灰色或半透明，表示其处于非活动状态。

从我个人经验来看，这两者的区别，远不止表面上那么简单。readonly 更像是一个“请勿触碰”的提示牌，告诉你这里有内容，但你不能改动。它的核心在于可读不可写。用户依然可以选中里面的文本，复制出来，甚至通过 JavaScript 去修改它的值（尽管这在用户界面上不直观）。更重要的是，当表单提交时，readonly 字段的值是会随着表单一起发送到服务器的。这对于展示一些预设值、计算结果，或者用户不能修改但又需要传递的数据非常有用。

disabled 则完全是另一种哲学。它就像把一个开关彻底关掉，甚至拔掉了电源。一个 disabled 的输入框，用户既不能编辑，也不能选中其内容。它在视觉上通常会变得灰蒙蒙的，给人一种“此路不通”的感觉。最关键的区别在于，disabled 的字段不会随表单一起提交。这意味着后端根本收不到这个字段的数据。所以，当你希望某个输入框在特定条件下完全不参与表单数据流时，disabled 是你的首选。它也常用于暂时禁用某些功能，直到满足特定条件（比如勾选了某个同意条款后，提交按钮才可用）。

从用户体验角度看，readonly 告诉用户“这是信息，但你不能改”，而 disabled 则是在说“这里现在没法用，或者根本就不需要你动”。选择哪个，往往取决于你希望用户如何感知这个输入框，以及它在数据提交中的角色。

何时选择Readonly而非Disabled？

这个问题，我经常在项目评审时被问到。我的答案通常是：当你需要向用户展示一些信息，这些信息是用户不能修改的，但同时这些信息又必须作为表单数据的一部分提交给后端时，readonly 是不二之选。举个例子，一个订单确认页面，你可能显示了商品的单价、数量、总价。用户可以看，可以复制，但不能修改。这些数据最终需要和订单一起提交。如果用 disabled，这些价格信息就不会被提交，那后端怎么知道用户买了什么价位的商品呢？

再比如，一个用户注册页面，你可能有一个“推荐人ID”字段，这个ID是系统自动填充的，用户只能看不能改。但你肯定希望这个ID能提交到后端，用来建立推荐关系。这时候，readonly 就派上用场了。它保持了数据的完整性，同时限制了用户操作。我甚至会用它来防止用户意外修改一些敏感的默认值，虽然前端限制不代表后端不校验，但至少能提供一个良好的用户体验。

它们对表单提交和后端处理的影响？

这是个非常实际的问题，尤其是在前后端交互时。我见过不少新手开发者在这里踩坑。最核心的区别在于数据流。

readonly 的字段，其 name 属性和 value 属性都会在表单提交时一并发送到服务器。这意味着，无论这个输入框的值是前端预设的，还是通过 JavaScript 动态填充的，后端都能正常接收到。这就像是你在寄快递，快递单上的信息，你写了“只读”，但快递公司还是会把这张单子和包裹一起送走。所以，在后端处理时，你可以直接通过表单参数获取到 readonly 字段的值，并进行后续的业务逻辑处理，比如保存到数据库、进行计算等等。

disabled 的字段则完全不同。它们在表单提交时，会被浏览器完全忽略。它们的 name 和 value 不会包含在 HTTP 请求体中。这就像你寄快递，但快递单被你撕掉了。快递公司根本不知道这个包裹是谁的，要寄到哪里。因此，后端是无法直接通过表单参数获取到 disabled 字段的值的。如果你后端需要这些数据，你必须通过其他方式传递，比如隐藏字段（type="hidden"）或者通过 JavaScript 在提交前动态启用（虽然这有点绕）。这种特性对于那些临时性、条件性的表单元素非常有用，比如一个“同意协议”的复选框没勾选时，提交按钮 disabled，这样提交按钮的值（如果有的话）就不会被发送，减少了不必要的后端处理。

JavaScript如何与Readonly和Disabled交互？

在前端开发中，JavaScript 对这两个属性的操控能力，是它们实用性的重要体现。

对于 readonly，JavaScript 可以非常自由地读取和修改它的 value 属性。

const myInput = document.getElementById('myReadonlyInput');
console.log(myInput.value); // 读取值
myInput.value = '新内容'; // 修改值，虽然用户界面上无法直接输入，但JS可以
myInput.readOnly = false; // 移除readonly属性，使其可编辑

这在很多场景下非常有用，比如你有一个计算器，用户输入A和B，结果C是 readonly 的，但C的值是JavaScript计算后填充进去的。或者根据用户选择的某个选项，动态更新一个 readonly 字段的提示信息。

而 disabled 属性，JavaScript 也可以读取和修改，但其行为会更“彻底”。

const myButton = document.getElementById('mySubmitButton');
myButton.disabled = true; // 禁用按钮
console.log(myButton.disabled); // true
myButton.disabled = false; // 启用按钮

当 disabled 属性被设置为 true 时，元素不仅视觉上被禁用，它也不会触发任何用户交互事件，比如 click、focus、input 等。这就是为什么你经常看到一个表单提交按钮在数据校验不通过时会 disabled，直到所有条件都满足才 enabled。这不仅防止了用户误操作，也避免了不必要的事件监听和处理。然而，需要注意的是，虽然 disabled 元素不触发事件，但 JavaScript 仍然可以读取和修改其 value 属性，只是这个值在表单提交时不会被发送。

总结来说，JavaScript 对 readonly 的操作更侧重于值的动态管理和属性的切换；而对 disabled 的操作则更多是关于元素可用状态的控制，以及与之相关的事件流的阻断。在实际开发中，理解这些细微之处，能帮助我们构建更健壮、更用户友好的前端应用。

今天关于《只读与禁用区别详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！