代理模式通过在真实写入对象前插入过滤逻辑实现敏感词拦截，即代理类的write()等方法先调用stripsensitivewords()净化数据，再委托给真实对象；需统一接口、预加载词库、按长度倒序使用str_replace、避免__call()滥用，并精准控制过滤粒度。
代理模式怎么介入数据写入前的敏感词过滤
代理模式本身不负责过滤逻辑，它只负责在真实对象操作前后加一层控制。想在数据写入前过滤敏感词，关键不是“用代理模式”，而是把敏感词过滤作为代理对象的前置拦截动作。PHP 中最直接的做法是让代理类的 write() 或类似方法先调用 filterSensitiveWords()，再委托给真实写入对象。
- 代理类必须持有真实写入对象（如
DatabaseWriter或FileLogger）的引用 - 过滤函数不能依赖全局状态，应接收原始字符串并返回净化后字符串，比如
stripSensitiveWords($text) - 如果原始数据是数组（如用户提交的
$_POST），代理需递归或按字段规则处理，不能只过滤单个$text参数 - 注意编码：若敏感词表是 UTF-8，但输入是 GBK，
mb_系列函数没指定编码会导致匹配失效
敏感词过滤函数该用 preg_replace 还是 str_replace
二者性能和语义差异明显：str_replace 快但只能做字面替换；preg_replace 支持模糊、边界、大小写不敏感等，但正则编译和回溯成本高。实际项目中，90% 的敏感词过滤场景用 str_replace 更稳妥。
- 用
str_replace时，敏感词列表必须按长度倒序排列（长词优先），否则 “法轮” 可能先被替换成 ***，导致 “法轮功” 剩余 “功” 漏过 - 若需支持通配或拼音变形，才考虑
preg_replace，但务必用PREG_UNMATCHED_AS_NULL和u修饰符，并预编译正则（preg_quote($word, '/')） - 避免在循环里反复调用
file_get_contents('sensitive_words.txt')—— 应在代理类构造时一次性加载并缓存为数组
代理类如何兼容不同写入目标（DB / Redis / 文件）
核心是定义统一接口，比如 Writable 接口含 save(array $data): bool 方法，然后让 DatabaseWriter、RedisWriter、FileWriter 都实现它。代理类 SensitiveWordProxy 不关心具体实现，只依赖这个接口。
- 代理类构造函数接收任意
Writable实例，不耦合具体类名 - 过滤逻辑集中在
save()入参处理：对$data中指定键（如'content'、'title'）做净化，其余字段透传 - 如果某些字段不该过滤（如加密后的
'token'），需通过白名单机制跳过，而非硬编码字段名 - 注意异常传递：过滤过程抛出的
InvalidArgumentException应保留原消息，但写入失败的异常不应被代理吞掉
为什么不要在 __call() 里做敏感词过滤
__call() 是兜底方法，仅当调用不存在的方法时触发。把它用于敏感词过滤，等于把业务逻辑藏在魔术方法里，既难调试，又破坏接口契约——别人看类型提示以为 save() 就是直写，结果暗地里改了数据。
- 明确的方法名（如
saveWithFilter()）比隐式__call()更易测试和 mock - IDE 无法识别
__call()提供的方法，补全和静态分析失效 - 若后续要加日志、限流、事务，全塞进
__call()会让方法职责爆炸 - 真正需要动态代理的场景（如 ORM 属性访问），才考虑
__get/__set，但敏感词过滤不属于这类
代理模式在这里的价值不是炫技，而是把“过滤”和“写入”这两个可变点解耦。最容易被忽略的是过滤的粒度控制——不是所有字符串都要过敏感词库，比如用户头像 URL、base64 图片内容、JWT payload，强行过滤反而引入误伤和性能损耗。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
