代理模式不适合敏感信息脱敏，因其解决访问控制而非数据变形；应使用accessor、策略类或统一脱敏函数，确保序列化前数据已脱敏。
代理模式在PHP中不适用于敏感信息脱敏展示——它解决的是“访问控制”或“延迟加载”问题，不是数据变形。真正该用的是访问器（accessor）、策略类或统一脱敏函数，而不是 Proxy 类去包装模型。
为什么代理模式不适合脱敏
代理模式本质是拦截对目标对象的调用，再决定是否转发、记录或增强行为。但脱敏不是“要不要访问”，而是“访问后返回什么值”。你无法靠一个 __call() 或 __get() 代理自动识别哪些字段要脱敏、按什么规则脱敏、是否受上下文影响。
- 代理无法感知字段语义：它不知道
$user->phone是手机号还是固话，更不会主动调用mask_phone() - 代理不处理嵌套结构：JSON 返回、DTO 数组、Eloquent 集合里的子项，代理对象本身不递归生效
- 代理和序列化冲突：Laravel 的
toArray()、jsonSerialize()绕过代理直接读属性，脱敏失效 - 代理增加间接层：调试时堆栈变深，错误定位更难；且每个模型都配代理类，维护成本远高于 accessor
Laravel 中该用 accessor 而不是 Proxy
如果你用 Laravel，getPhoneMaskedAttribute() 是标准解法。它天然满足“读取时转换、写入时透明、序列化可配置”三个关键点。
- 必须把字段加进
$appends，否则toArray()不包含它 - 原始字段不能在
$hidden里，否则$this->attributes['phone']拿不到值 - 别在 accessor 里做 DB 查询或 HTTP 请求，会拖慢整个集合序列化
- 若需角色区分（如管理员看全量），在 accessor 内部用
auth()->user()?->is_admin判断，不要拆成多个 accessor
需要动态策略时，用策略类而非代理
当脱敏规则随请求来源、用户角色、导出格式变化时，应封装为策略类，例如 PhoneMaskStrategy::forContext($request)，而不是让 Proxy 去“适配”。
- 策略类接收上下文（如
$request->is('api/*')、auth()->id()），返回具体脱敏函数 - 控制器中统一调用：
$data = array_map(fn($u) => ['phone' => $strategy->mask($u['phone'])], $users) - 导出 CSV 时传入
'export'上下文，API 返回时传'api'，逻辑隔离清晰 - 避免在 Proxy 构造时就绑定策略，导致单例复用错乱或上下文丢失
json_encode 前没脱敏等于白干
无论你用 accessor、策略类还是数组映射，最终输出前必须确保 json_encode() 接收的是已脱敏的数据副本。这是最容易被忽略的一环。
- ORM 直接
json_encode($user)？不行——除非你重写了jsonSerialize()并在里面调用了脱敏逻辑 - 用 DTO 对象？必须在
toArray()或__toArray()方法里显式调用DataMasker::phone($this->phone) - 日志打点也得脱敏：
Log::info('user', ['phone' => DataMasker::phone($user->phone)])，否则$user->phone原样进日志
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
