webman脱敏必须在php层、swoole响应前完成，推荐注解+自定义序列化器统一处理，禁用前端拼接、模板运行时处理及仅依赖数据库视图，需覆盖所有出参路径并分级管控规则。
Webman 是 PHP 框架，不是 Python 工具 —— 所有脱敏逻辑必须落在 PHP 层、Swoole 响应生命周期和视图渲染环节，不能依赖前端或外部代理“事后补救”。
脱敏必须在后端响应前完成，不能靠前端 JS
很多人把手机号写成 138****8888 交给前端拼接，这是危险的。一旦接口被直接调用（如 Postman、爬虫、内部系统集成），原始数据就裸奔了。Webman 的控制器返回 JSON 或 HTML 前，敏感字段必须已脱敏。
- 脱敏动作应发生在 Controller 返回数据之前，或 Service 构建 DTO/VO 时
- 禁止在 Blade/Twig 模板里用
{{ $user->phone|substr_replace }}这类运行时处理 —— 模板无类型校验、不可复用、易漏 - 若用 JSON 接口，脱敏必须在
json_encode()前完成；若用 HTML 渲染，应在 assign 到 view 之前处理
用注解 + 自定义序列化器统一脱敏（推荐）
Webman 支持基于 think-orm 或 illuminate/database，配合 Jackson 风格的注解方案最可控。核心是拦截 json_encode() 前的数据序列化过程。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 在 DTO 类字段上加自定义注解，如
@MobileDesensitize、@IdCardDesensitize - 注册全局
JsonSerializer，检测到该注解时，对值执行preg_replace('/^(\d{3})\d{4}(\d{4})$/', '$1****$2', $value) - 避免每个 Controller 写
str_replace，否则字段一多就漏 —— 注解驱动才是可维护的
数据库视图层脱敏仅适用于角色隔离强场景
如果你的业务明确区分“管理员查全量、普通用户只能看脱敏”，MySQL 视图确实可行，但 Webman 项目中需注意：
- 视图必须由 DBA 统一管理，开发不能随意
CREATE VIEW，否则权限失控 - Webman 的
DB::table('user_info_view')查询结果无法再被 ORM 关联，with()会失效 - 视图不解决 API 被越权调用的问题 —— 如果攻击者拿到管理员 token，照样看到明文，仍需 RBAC 校验
- 视图脱敏只覆盖 SELECT，INSERT/UPDATE 仍需在 PHP 层校验输入（如禁止普通用户提交完整身份证）
环境变量和配置层别暴露脱敏规则本身
脱敏不是“越遮越多”，而是按需分级。比如测试环境显示 1381234****，生产环境强制 138****8888。规则本身也是敏感配置。
- 不要把脱敏正则写死在 config 文件里，例如
'phone_mask' => '/^(\d{3})\d{4}(\d{4})$/' - 改用
getenv('DESENSITIZE_LEVEL')控制粒度，值为none/partial/full，再映射到具体逻辑 - 确保
.env文件不在 Web 根目录下，且 Web 服务器（Nginx/Apache）已配置禁止访问.env
真正难的不是写一个 maskPhone() 函数，而是让所有出参路径（JSON、HTML、Excel 导出、WebSocket 推送）都经过同一套脱敏管道 —— 否则只要漏掉一个导出接口，整套策略就形同虚设。
