1.1 什么是textarea只读属性
textarea的只读属性就像给文本区域上了一把“软锁”。用户可以看到里面的内容，可以选中复制，但不能直接修改。想象一下博物馆里展出的珍贵手稿——隔着玻璃你能看清每个字，就是没法在上面涂改。
这个特性通过简单的HTML属性就能实现。在textarea标签里加上readonly，它就变成了只能看不能改的状态。我刚开始学前端时，曾经把readonly和disabled搞混，结果表单数据提交时遇到了麻烦。后来才明白，只读状态的数据是会随表单一起提交的，而禁用的不会。
1.2 只读属性的应用场景
只读textarea在很多实际场景中都能派上用场。最常见的是表单预览功能——用户填写完信息后，在确认页面用只读方式展示已填内容。这样既保证了数据的完整性，又避免了误操作。
另一个典型场景是内容展示。比如博客系统的评论审核页面，管理员需要查看用户提交的评论内容，但又不应该直接修改原内容。这时候只读textarea就特别合适。
权限控制也是个重要用途。不同用户角色对同一文本区域的编辑权限可能不同。普通用户只能查看，管理员才能编辑。这种差异化权限管理在很多后台系统都很常见。
1.3 只读与正常状态的区别
从外观上看，只读textarea和普通textarea差别不大。可能背景色稍微浅一些，但本质上还是那个熟悉的文本框。真正的区别在于交互体验——鼠标移上去不会变成输入光标，键盘输入也不起作用。
有个细节值得注意：只读状态下用户仍然可以选中文本进行复制。这个特性在需要展示重要信息时特别有用。比如订单确认页面显示收货地址，用户可能需要复制地址到剪贴板。
从开发角度来说，只读状态的数据流向也值得关注。它保留了完整的表单功能，数据会正常提交到服务器。这点和禁用状态完全不同，禁用的表单元素根本不会参与数据提交。
我记得有个项目就因为没处理好这个区别，导致用户在预览页面无法提交完整数据。后来改用只读属性才解决了问题。
textarea[readonly] { background-color: #f5f5f5; border-color: #ddd; color: #666; }
4.1 表单预览场景
用户填写完表单后，预览确认是个很常见的需求。这时候把表单字段设为只读，既能让用户完整看到自己输入的内容，又能防止意外修改。
我参与过一个在线简历制作项目，用户在编辑完个人信息后进入预览页面。所有textarea都设置为readonly，包括个人介绍、工作经历这些长篇内容。用户反馈说这样很安心，不用担心误触键盘导致辛苦填写的内容被改掉。
预览场景还有个细节值得注意——保留文本选择功能。用户可能需要复制部分内容到其他地方，或者只是习惯性地选中文字来帮助阅读。readonly完美支持这些操作，而disabled就不行。
从技术实现角度，预览页面通常直接复用编辑页面的HTML结构，只是加上readonly属性。这种设计既节省开发成本，又保证了两边样式的一致性。
4.2 数据展示场景
有些情况下，textarea纯粹用来展示数据，压根不需要编辑功能。比如后台管理系统的日志查看器，或者客服系统的聊天记录展示。
上周帮朋友公司调试一个工单系统，他们用textarea显示系统自动生成的故障报告。最初设计是可编辑的，结果有客服不小心修改了报告内容，导致技术团队分析问题时被误导。改成readonly后，这类问题再没发生过。
数据展示场景中，内容的完整性很重要。用户可能需要仔细阅读大段文字，甚至需要复制部分内容进行搜索。readonly在保护数据的同时，完全支持这些使用需求。
另一个例子是代码展示。虽然现在有专门的代码高亮组件，但在简单场景下，用readonly的textarea展示代码片段也是个不错的选择。用户可以直接复制代码，又不用担心误操作。
4.3 权限控制场景
权限管理是web应用中绕不开的话题。不同权限的用户对同一textarea可能有不同的操作权限，readonly在这里发挥着重要作用。
想象一个内容审核系统。普通编辑可以自由修改文章内容，但审核员只能查看不能修改。这时候根据用户角色动态设置textarea的readonly状态，就能实现精细的权限控制。
我印象很深的一个项目是合同管理系统。法务人员起草合同时，某些条款区域对业务人员是只读的，防止非专业人士修改法律条文。这种设计既保证了专业性，又不影响业务人员查看合同内容。
权限控制通常需要前后端配合。后端返回用户权限信息，前端根据权限动态设置textarea状态。这种方案比完全依赖后端校验更友好，能给用户即时的反馈。
4.4 多步骤表单应用
多步骤表单在现代web应用中越来越普遍。用户在后续步骤中可能需要回顾前面步骤填写的内容，但不能直接修改——这正是readonly的用武之地。
注册流程是个典型例子。用户填写完基本信息后进入下一步，之前的信息以只读形式展示在页面顶部或侧边栏。这样既提供了上下文参考，又避免了流程混乱。
电商结账流程也大量使用这种模式。收货信息确认页面把地址详情用readonly的textarea展示，用户可以确认信息是否正确，需要修改时再回到上一步。
多步骤表单的设计哲学是“一次只让用户专注一件事”。readonly帮助实现这个目标，让用户在当前步骤专注于当前任务，同时又能看到整体进度。
实际开发中，我习惯把这种只读展示区和可编辑区分开设计。只读区域通常样式更简洁，重点突出内容本身。这种视觉区分帮助用户快速理解界面逻辑。
5.1 只读属性的兼容性考虑
readonly属性在现代浏览器中表现相当稳定，但总有些边缘情况需要留意。IE老版本偶尔会出现样式渲染问题，特别是当textarea内容动态更新时。
我记得有个政府项目需要兼容IE11，发现设置readonly后光标依然闪烁。虽然不影响功能，但用户会觉得这个字段还能编辑。最后通过CSS的caret-color属性把光标颜色设为透明才解决。
移动端浏览器的表现也值得关注。iOS Safari在textarea只读时仍然允许用户触发虚拟键盘，虽然输入不会生效，但这种体验确实不够完美。可以考虑在移动端使用contenteditable="false"作为备选方案。
表单验证时要注意，readonly字段的值是正常提交的。有些开发者会误以为需要特殊处理，其实完全按照普通字段处理就行。这个特性在数据回显时特别有用。
5.2 样式定制技巧
只读textarea的默认样式往往过于朴素，用户可能意识不到这是只读内容。适当的样式调整能显著提升用户体验。
背景色微调是个简单有效的方法。给readonly的textarea加上浅灰色背景，既保持了可读性，又暗示了不可编辑状态。我一般用#f5f5f5这个色值，对比度刚刚好。
边框样式也能传递状态信息。把边框色从默认的深色改为浅灰色，或者使用虚线边框，都能让用户直观理解当前状态。记得保持足够的对比度，确保文字清晰可读。
字体颜色其实可以保持不变。有些设计师喜欢把文字调灰，但这样会影响阅读体验。保持黑色文字，通过背景和边框来暗示状态，这样既明确又友好。
鼠标样式也别忘了调整。加上cursor: not-allowed或者cursor: default，避免出现文本输入的光标。这个小细节能让交互意图更加清晰。
5.3 性能优化建议
大量只读textarea同时渲染时，性能问题可能悄悄出现。特别是当内容很长或者数量很多的时候。
虚拟滚动是个不错的解决方案。只渲染可视区域内的textarea，其他的用div替代。我在一个日志查看系统中用过这种方案，页面加载速度提升了近三倍。
动态设置readonly属性时，避免频繁操作DOM。如果需要批量设置，先把所有textarea收集起来，然后一次性处理。这个技巧在表格编辑场景中特别实用。
内容较长的只读textarea，考虑使用懒加载。先加载可见部分，用户滚动时再加载剩余内容。这种方案在移动端效果尤其明显。
CSS选择器的使用也要注意。避免使用过于复杂的选择器来定位readonly元素，简单的类名选择器性能要好得多。给只读textarea加个特定class，然后基于这个class写样式。
5.4 常见问题解决方案
用户反映最多的可能是复制功能失效。这通常是因为误用了disabled属性，或者CSS中设置了user-select: none。确保readonly的textarea保持文本选择能力。
动态内容更新时，有些开发者会先移除readonly属性，更新内容后再加回去。其实完全没必要，readonly状态下直接修改value属性是完全可行的。
表单提交时，记得验证只读字段的值是否符合预期。虽然用户不能修改，但JavaScript还是可以修改的。重要的数据最好在后端再做一次校验。
无障碍访问经常被忽略。记得给只读textarea加上aria-readonly="true"属性，屏幕阅读器用户才能正确理解控件状态。这个简单的改动能让残障用户获得更好的体验。
移动端还有个细节——防止页面缩放。有些浏览器在focus只读textarea时会自动缩放页面，可以通过viewport设置或者阻止focus事件来避免。
最后提醒一点，readonly不是安全措施。敏感信息不要依赖前端只读来保护，该加密的还是要加密，该权限控制的还是要做服务端校验。
