Vue.js 的 readonly 是运行时只读提示机制而非硬性访问控制，通过 Proxy 拦截赋值等操作并在开发环境警告、生产环境静默；无法阻止嵌套对象修改，需递归应用或配合 computed、watch、TypeScript 等实现可靠保护。
Vue.js 的 readonly 并不真正“阻止”修改，而是通过 Proxy 拦截赋值操作并抛出开发环境警告，它本质是运行时只读提示机制，不是硬性访问控制。要实现可靠的数据保护与状态变更拦截，需结合 readonly、shallowReadonly、自定义响应式包装及业务层约束。
readonly 的实际行为与局限
readonly 返回一个响应式对象的只读代理，对属性赋值（如 obj.x = 1）、删除（delete obj.x）、重配置（Object.defineProperty）等操作，在开发模式下会触发 console.warn 并静默失败；生产模式下无警告且完全静默。它无法防止对象内部嵌套对象被意外修改（除非整个嵌套结构也被 readonly 包裹）。
- 深层响应式对象需递归应用
readonly，或使用markRaw配合手动冻结（不推荐用于响应式数据） - 数组索引赋值（
arr[0] = x）、push/pop等方法调用均被拦截并警告 - 不能阻止解构后对原始变量的重新赋值（
const { x } = readonlyObj; x = 2不报错，但只是改了局部变量）
组合 readonly 与 computed 实现逻辑只读
对于需要“逻辑上不可变但可响应更新”的场景（如从 store 派生的视图状态），应避免直接暴露响应式源，而用 computed + readonly 封装：
- 用
computed(() => ({ ...state }))派生新对象，再套readonly()，确保外部无法修改派生结果 - 若派生逻辑含副作用或需缓存，优先用
computed而非readonly(ref(...)) - 组件 props 默认就是只读的，无需额外包装；但子组件仍可通过
toRefs解构后误改 —— 建议在接收端用readonly(toRefs(props))显式加固
拦截变更：用 watch 或自定义 set 拦截器补充
readonly 本身不提供拦截回调。如需在“尝试修改只读数据”时执行日志、上报或降级处理，需在业务层主动管控：
立即学习“前端免费学习笔记（深入）”；
- 对关键状态使用
ref或reactive，配合watch监听变化，并在 handler 中校验来源（例如比对调用栈或标记 mutation 类型） - 封装自定义 Hook，如
useProtectedState(initial, onAttemptedChange)，内部用ref存储值，所有 setter 都先走拦截逻辑 - 在 Pinia store 中，将 state 设为私有（
_state），仅暴露readonly($state)的 getter，所有变更必须走明确定义的 action
生产环境的加固建议
开发期的 readonly 警告在生产环境消失，因此不能依赖它做安全边界：
- 敏感数据（如用户权限、支付状态）应在服务端校验，前端只负责展示和轻量交互
- 对关键响应式对象，可在初始化时用
Object.freeze冻结其顶层属性（注意：会丢失响应性，仅适用于静态配置） - 利用 TypeScript 的
readonly类型修饰（如readonly name: string）在编译期提示错误，与运行时readonly()形成双重保障
