应定义全局response()函数于启动文件中，设JSON头、echo后exit，支持$http_status与业务$code分离，CLI环境需规避，敏感字段由调用方预处理，严禁return代替输出。
怎么写一个全局可用的 response() 函数
PHP 没有内置的统一响应函数，得自己封装。最稳妥的方式是定义一个全局函数，放在项目启动时自动加载的文件里（比如 bootstrap.php 或 functions.php），而不是塞进某个类里——否则控制器里还得 use 或 new，反而增加调用成本。
常见错误是直接 echo JSON 后不 exit，导致后续代码继续执行、响应体被污染；或者忘了设 Content-Type，前端收到 text/html 导致解析失败。
- 必须在输出前调用
header('Content-Type: application/json; charset=utf-8') - 必须在
echo后加exit或die，防止后续逻辑干扰 - 不要依赖框架的自动 JSON 包装（比如 Laravel 的
response()->json()），纯 PHP 项目没这层 - 建议默认返回
200 OK，错误时再显式改状态码，别反着来
status 参数该不该支持 HTTP 状态码数字
应该支持，而且要区分语义：数字用于精确控制（比如 401、422），字符串如 'success' 或 'error' 只用于业务层标记，不能替代 HTTP 状态码。
很多人把 status => 'fail' 和 http_response_code(400) 混在一起用，结果 Nginx 或 CDN 缓存了 200 响应，因为没真正发出去非 2xx 的状态行。
立即学习“PHP免费学习笔记（深入）”；
- 函数签名建议为
response($data, $message = '', $code = 200, $http_status = 200) -
$http_status直接透传给http_response_code()，不转换、不映射 - 前端只认
http_status，$code是业务码（比如1001表示“用户不存在”） - 避免在函数里做状态码到文案的硬编码映射，那属于中间件或配置层的事
怎么安全地处理敏感字段（比如 password、token）
统一响应函数本身不该负责脱敏，那是数据组装阶段的事。但可以提供轻量钩子，比如允许传入一个 $filter 回调，在 JSON 输出前清理数据。
常见错误是试图在 response() 里递归遍历所有键名匹配 'password'，结果误删了正常字段（比如 old_password、password_hint），或者漏掉嵌套结构里的敏感值。
- 推荐做法：调用方在传入
$data前自行过滤，例如用unset($user['password']) - 如果真要加过滤能力，只接受白名单字段数组，比如
['password', 'api_token']，不搞模糊匹配 - 永远不要在
response()中修改原始数组引用，用array_filter()或array_diff_key()返回新数组 - 注意 JSON 编码对资源类型（如 MySQL result）会报错，
response()应提前检测并抛出明确异常，比如Cannot JSON encode resource #123
为什么不能直接 return 数组，而必须 echo + exit
因为 PHP 的 SAPI（如 Apache mod_php、PHP-FPM）是“输出即响应”，return 只是把数组交还给上层调用栈，并不会终止请求流。如果你在控制器里写 return response(...)，而外面没有 echo 或 exit，响应就空了。
另一个坑是用了 ob_start() 却没清空缓冲区，导致多次调用 response() 时内容叠加，前端看到乱码或双 JSON。
- 函数体内必须包含
echo json_encode(...)+exit，不能只 return - 避免在 CLI 环境下调用它（比如单元测试或命令行脚本），那里没有 HTTP 头概念，会警告 “headers already sent”
- 可以用
PHP_SAPI === 'cli'做环境判断，CLI 下改用 var_dump 或 error_log - 别信“框架自动处理了”，原生 PHP 项目里，每个响应出口都得亲手把关
最常被忽略的是错误场景下的响应一致性：比如数据库查询失败时，有人 throw Exception，有人 return false，有人直接 die。统一响应函数救不了逻辑混乱，它只负责“怎么吐”，不负责“该不该吐”。
