Vue3 的 readonly vs shallowReadonly：深入对比

1. 邂逅响应式的两面性

在Vue3的响应式系统中，readonly和shallowReadonly就像两个性格迥异的门卫，它们共同守护着数据的安全边界。我们先看一个真实的场景：当你开发需要共享配置对象时，既希望其他开发者能方便读取数据，又要确保核心配置不被意外修改。此时这对堂兄弟就派上了大用场。

<script setup>
// 技术栈：Vue3 Composition API
import { reactive, readonly, shallowReadonly } from 'vue'

// 原始响应式对象
const config = reactive({
  appName: '电商平台',
  version: '3.2.1',
  apiSettings: {
    baseURL: 'https://api.example.com',
    timeout: 5000
  }
})

// 创建深层只读代理
const frozenConfig = readonly(config)
// 创建浅层只读代理
const surfaceConfig = shallowReadonly(config)

// 尝试修改深层只读对象
frozenConfig.appName = '新名称' // ❌ 控制台警告且修改无效
frozenConfig.apiSettings.timeout = 3000 // ❌ 同样会被阻止

// 修改浅层只读对象的根属性
surfaceConfig.appName = '测试名称' // ❌ 根级属性被锁定
surfaceConfig.apiSettings.timeout = 2000 // ✅ 嵌套属性可修改
</script>

这两个API的行为差异在这个简单示例中已初现端倪：readonly犹如严密的防盗网，对所有层级的属性都实施保护；而shallowReadonly则像是带小门的围栏，仅封锁最外层通道。

2. 核心原理与技术解密

2.1 响应式系统的DNA

要深入理解这对API，必须了解Vue3的响应式基本原理。Proxy代理在初始化时会为每个属性创建依赖追踪，当访问嵌套对象时，会自动递归创建子代理。这个机制解释了为什么readonly能够实施深度保护。

// 模拟实现原理（简化版）
function customReadonly(target) {
  return new Proxy(target, {
    get(target, key) {
      const result = Reflect.get(target, key)
      // 递归处理对象类型值
      return isObject(result) ? customReadonly(result) : result
    },
    set() {
      console.warn('不可修改只读属性')
      return false
    }
  })
}

// 对比shallow实现
function customShallowReadonly(target) {
  return new Proxy(target, {
    get(target, key) {
      return Reflect.get(target, key) // 不再递归处理
    },
    // 相同set陷阱
  })
}

2.2 性能博弈的临界点

当我们处理包含10层嵌套的大型对象时，性能差异会非常明显：

// 创建测试对象
const deepObject = reactive({
  level1: { level2: { /* ... */ } } // 共10层嵌套
})

// 耗时测试
console.time('deepReadonly')
const deep = readonly(deepObject) // 递归创建所有代理
console.timeEnd('deepReadonly') // ≈3.2ms

console.time('shallowReadonly')
const shallow = shallowReadonly(deepObject) // 仅处理根级
console.timeEnd('shallowReadonly') // ≈0.4ms

实验表明，在极端嵌套场景下，readonly的初始化耗时可能达到shallowReadonly的8-10倍。这种差异在大规模数据操作时需要特别注意。

3. 战场实践：典型应用场景

3.1 全局配置守卫者

在微前端架构中，主应用向子应用传递配置时：

// 主应用封装配置
const sharedConfig = shallowReadonly({
  authToken: 'Bearer xxxx',
  themeConfig: { color: '#1890ff' }
})

// 子应用接收
export function initSubApp(config) {
  // 可读取主题配置但无法修改令牌
  config.themeConfig.color = '#f5222d' // ✅ 允许修改（设计决策）
  config.authToken = '恶意令牌' // ❌ 被阻止
}

这里采用shallowReadonly的好处在于：允许子应用根据需求自定义样式主题，但核心认证信息保持不可篡改。

3.2 组件道具的保险锁

在跨组件通信时保护重要参数：

<script setup>
// 技术栈：Vue3 + TypeScript
import { shallowReadonly } from 'vue'

interface ComponentProps {
  userInfo: {
    name: string
    permissions: string[]
  }
}

const props = defineProps<ComponentProps>()

// 导出部分数据时进行防护
export const safeUserInfo = shallowReadonly({
  ...props.userInfo,
  permissions: [...props.userInfo.permissions] // 深拷贝数组
})

// 消费组件中
safeUserInfo.name = '新名字' // ❌ 属性只读
safeUserInfo.permissions.push('admin') // ❌ 由于深拷贝被阻止
</script>

这种组合策略既防范了根属性修改，又通过深拷贝保护了引用类型的值，实现了多层次防御。

4. 技术方案选型指南

4.1 决策树可视化

通过流程图帮助开发者快速决策：

                          ┌─────────────┐
                          │ 需要完全不可变？ │
                          └──────┬──────┘
                                 │
                  ┌──────────────▼─────────────┐
                  │数据包含深层次嵌套结构？         │
                  └──────────────┬─────────────┘
                                 │
              ┌─────────Yes──────┴──────No───────┐
              │                                   │
        ┌─────▼─────┐                     ┌──────▼─────┐
        │  readonly │                     │ shallowR/O │
        └───────────┘                     └────────────┘

4.2 混搭使用策略

聪明的开发者会将两者结合，在复杂场景中发挥各自优势：

const smartConfig = readonly({
  core: shallowReadonly({
    apiKeys: ['key1', 'key2'],
    endpoints: { users: '/api/users' }
  }),
  // 其他可安全修改的配置
  uiSettings: {
    theme: 'light'
  }
})

// 访问路径：
smartConfig.core.apiKeys.push('key3') // ❌ 浅层只读保护
smartConfig.core.endpoints.users = '/new' // ✅ 内层可修改
smartConfig.uiSettings.theme = 'dark' // ✅ 允许修改

这种嵌套防护创造了一个灵活的配置体系：核心部分坚如磐石，界面设置允许动态调整。

5. 常见陷阱与防御指南

5.1 原型污染漏洞

当处理包含构造函数的对象时，需要注意原型链问题：

class ConfigTemplate {
  constructor() { this.version = '1.0' }
}

const raw = reactive({ 
  protoExample: new ConfigTemplate()
})

const protectedConfig = shallowReadonly(raw)

// 通过原型链修改
protectedConfig.protoExample.__proto__.version = '危险版本' // ✅ 仍然生效！

防御方案：

const safeConfig = shallowReadonly({
  protoExample: Object.create(null, {
    version: { value: '1.0', writable: false }
  })
})

5.2 异步操作中的定时炸弹

在定时器回调中意外修改只读属性：

const timerConfig = shallowReadonly({
  interval: 1000,
  params: { retry: 3 }
})

setInterval(() => {
  timerConfig.params.retry-- // ✅ 允许修改但可能导致问题
  timerConfig.interval = 500 // ❌ 修改失败但可能导致混乱
}, timerConfig.interval)

推荐安全模式：

// 创建防御副本
const safeParams = readonly({ ...timerConfig.params })
Object.freeze(timerConfig.params)

6. 综合评估与技术选型

6.1 功能维度对比表

6.2 生态适配性分析

在SSR场景下，需要特别注意：

// Nuxt3服务端处理示例
export const useSharedState = () => {
  const state = reactive({ /* ... */ })
  if (process.server) {
    return shallowReadonly(state) // 避免深层次序列化问题
  }
  return readonly(state)
}

7. 最佳实践路线图

1. 安全优先：默认使用readonly，仅在必要时降级
2. 性能敏感区：对高频访问数据采用shallowReadonly
3. 防御性封装：关键配置结合Object.freeze
4. 类型强化：配合TypeScript实现编译时校验
5. 监控系统：在开发环境开启严格模式