前言
遇到一个小坑，记录一下。做微信小程序的时候，习惯性地给 input 组件加了个 readonly 属性，想着这不就是只读么？结果一跑，发现输入框依然能点、能聚焦、还能长按复制，完全没听话。翻了下文档，发现这事儿没那么简单，干脆把排查过程和方案一并整理出来。
一、问题定位
微信小程序里，input 设置了 readonly 属性后，仍然可以交互。这通常逃不出三个原因：
- readonly 的先天限制：它只管阻止键盘弹出，聚焦和长按复制这类行为并不在拦截范围内。
- 事件冒泡没处理：touch、click 事件照样往上冒，组件的行为就“失控”了。
- 样式冲突：CSS 的优先级或覆盖规则，可能把只读的视觉效果给冲掉了，用户看着像可编辑一样。
二、核心解决方案
方案一：用 disabled 替代
最暴力的方法，直接上 disabled，一了百了。
特点：
- 交互完全禁止，用户没法点、没法选、没法复制。
- 组件默认变灰，视觉上明确告诉你“这儿动不了”。
- 最适合表单提交前的禁用场景。
方案二：事件阻止方案
如果非得保留 readonly 属性，那就得手动掐掉事件传播。
Page({
preventTap(e) {
// 阻止默认行为
return false;
},
preventTouch(e) {
// 阻止触摸事件
return false;
}
})
这样写的好处是，input 还能聚焦（如果后续需要做焦点控制），但所有点按操作都被拦截了。
方案三：CSS 控制交互
纯样式层面的拦截，也算一个轻量方案。
/* 禁止所有交互 */
.search-input {
pointer-events: none;
-webkit-user-select: none;
user-select: none;
}
/* 如果只是想禁止文本选择，保留点击等交互 */
.search-input {
user-select: none;
}
pointer-events: none 的副作用是整个组件层叠上下文都会被穿透，需要评估是否影响页面其他元素的点击。
三、替代方案推荐
方案一：用 view 组件展示
如果只是纯展示文本，干嘛非用 input？一个 view 就能搞定，还省去一堆兼容问题。
请输入你需要搜索的型号
方案二：条件渲染
根据只读状态切换组件，只读时显示 view，可编辑时显示 input。
{{searchValue}}
这种做法的好处是彻底分离只读和编辑两种状态，代码逻辑一目了然。
四、最佳实践建议
根据不同的业务场景，直接对号入座就好：
- 纯展示场景 → 用
view组件，简单靠谱。 - 表单禁用场景 → 用
disabled属性，省心省力。 - 需要聚焦但不可编辑 →
readonly+ 事件阻止，保持焦点控制。 - 临时只读需求 → CSS
pointer-events: none，快速切换。
五、注意事项
- 真机测试：有些属性在模拟器里好用，真机上一跑就现原形，尤其是事件冒泡和
pointer-events。 - 样式适配：
disabled状态默认变灰，记得检查 UI 兼容性，别让视觉风格和周边组件脱节。 - 用户体验：只读状态一定要给用户明确反馈，置灰、加提示文案、加图标都行，别让人对着一个看似可编辑的框干着急。
- 版本兼容：部分属性和行为依赖基础库版本，生产环境前最好确认一下。
六、完整示例代码
最后，如果非要用 readonly 但又想完全禁止操作，可以这样组合起来用：
Page({
data: {
searchValue: ''
},
preventAction() {
wx.showToast({
title: '当前不可编辑',
icon: 'none'
})
return false;
}
})
.readonly-style {
background-color: #f5f5f5;
color: #999;
}
按以上方案实施，readonly 失效的问题基本能一一击破。根据场景选对方法，比满大街找“万能代码”靠谱得多。
