readonly字段可正常提交，前提是必须有合法name属性；常见不提交原因包括缺失name、误用disabled、滥用display:none/visibility:hidden或手动覆盖asp-for生成的name。
readonly 属性本身就能提交数据，前提是必须有 name
只读但可提交，不是“需要额外操作”的功能，而是浏览器原生行为——只要 input 或 textarea 同时满足两个条件：① 有 readonly 属性；② 有合法的 name 属性，它的值就会出现在表单提交结果中（FormData、URLSearchParams 或后端接收到的键值对里）。
常见错误是以为加了 readonly 就万事大吉，却漏掉 name：
- 没写
name→ 浏览器直接忽略该字段，不打包进任何提交数据 - 写了
disabled替代readonly→ 值彻底消失，连name都不发 - 用
display: none包裹input→ DOM 还在，但可能干扰布局或引发重复绑定（尤其在 ASP.NET Core 中） - 手动覆盖
name（如name="delivery"），而模型绑定期望的是DeliveryCharge→ 后端收不到或绑定失败
最简验证方式：<input type="text" name="test" value="123" readonly>，提交后检查 Network → Form Data，能看到 test=123。
readonly 和 disabled 的行为差异必须分清
两者都让输入框不能编辑，但语义和底层机制完全不同：
-
readonly：禁输入，但保留聚焦、选中、复制能力；值参与表单序列化；默认样式无变化（需 CSS 主动优化） -
disabled：完全脱离表单交互流；无法聚焦、无法右键、屏幕阅读器可能跳过；值绝不会出现在提交数据中
典型误用场景：
- 用户 ID 显示框用了
disabled→ 后端拿不到 ID，权限校验失败 - 订单号展示区加了
disabled+tabindex="-1"→ 看似“只读”，实则连复制都禁了，体验倒退
记住一句判断标准：需要后端接收这个值？→ 必须用 readonly；纯粹临时禁用且不关心值？→ 才用 disabled。
ASP.NET Core 中用 asp-for 是最稳妥的写法
Razor Pages / MVC 场景下，手写 name 容易出错，asp-for 能自动生成匹配模型属性的 name、id 和初始 value，同时兼容 readonly：
<input readonly asp-for="DeliveryCharge" type="number" step="0.01">
它等价于（假设模型属性名为 DeliveryCharge）：
<input readonly name="DeliveryCharge" id="DeliveryCharge" value="12.50" type="number" step="0.01">
关键点：
- 不要额外加
<input type="hidden" asp-for="DeliveryCharge">—— 会触发重复绑定，decimal 类型可能转成字符串导致验证失败 - 不要用 CSS 隐藏主输入再塞一个隐藏域 —— 布局混乱、JS 更新值时容易不同步
- JS 动态更新值时，直接改
element.value即可，不影响提交逻辑
JavaScript 控制 readonly 状态时大小写不能错
DOM 属性名是 readOnly（驼峰，O 大写），不是 readonly：
- ✅ 正确：
inputEl.readOnly = true或inputEl.readOnly = false - ✅ 正确：
inputEl.setAttribute('readonly', '')或inputEl.removeAttribute('readonly') - ❌ 错误：
inputEl.readonly = true（小写readonly是无效属性，赋值无效果） - ❌ 错误：
inputEl.setAttribute('readonly', 'true')（布尔属性不该带值，部分旧浏览器解析异常）
另外注意：readonly 元素仍能触发 focus、select、copy 事件，适合需要用户复制结果的场景（比如订单号、计算金额），这点和 disabled 完全不同。
最容易被忽略的一点是：readonly 不改变表单控件的原始 type 解析逻辑。比如 type="number" 的只读输入框，提交的仍是数字字符串（如 "12.50"），后端模型绑定必须能处理这种格式，不能假设它自动转成数字类型。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
