php接口错误响应须脱敏：禁用display_errors，启用log_errors写入受控日志；统一try-catch捕获exception/error，返回标准化json（含业务code、前端友好message）；http状态码准确，但响应体不暴露技术细节、路径、堆栈或用户输入。
PHP接口返回错误时，不能直接暴露敏感信息（如数据库路径、SQL语句、服务器绝对路径、堆栈跟踪），否则违反安全合规要求（如等保2.0、GDPR、金融行业接口规范）。核心原则是：对内可查，对外可控。
错误响应必须过滤敏感字段
PHP默认开启display_errors或未捕获异常时，error_log可能被输出到响应体，导致泄露。生产环境必须禁用display_errors，改用log_errors写入日志文件。
-
display_errors = Off（php.ini 或运行时用ini_set('display_errors', '0')） -
log_errors = On，并确保error_log指向受控路径（如/var/log/php/error.log，权限设为640） - 所有接口入口统一用
try...catch包裹，Exception和Error都要捕获，返回标准化 JSON 错误结构
使用 http_response_code() + 自定义错误体
HTTP 状态码要真实反映错误类型（如 400 表参数错误，401 表认证失败，403 表权限不足，500 表服务端未预期错误），但响应体中不能含技术细节。
http_response_code(400);
echo json_encode([
'code' => 40001,
'message' => '请求参数格式错误',
'data' => null
]);
-
code是业务错误码（非 HTTP 状态码），由后端统一维护文档，前端只依赖它做分支处理 -
message仅用于前端提示或调试日志，禁止出现mysqli_error、file_get_contents(): failed to open stream等原始报错 - 绝不返回
trace、file、line字段给调用方
第三方库报错需主动封装
比如调用 curl_exec() 失败、pdo->prepare() 抛出异常、Redis 连接超时等，原始错误信息都含环境特征。必须拦截并映射为通用错误。
立即学习“PHP免费学习笔记（深入）”；
- 对
PDOException：检查$e->getCode()（如 23000 表唯一约束），转成业务码如40902，message改写为“手机号已被注册” - 对
cURL错误：用curl_errno($ch)判断（如CURLE_COULDNT_CONNECT），返回“上游服务暂不可用”，而非“Connection refused” - 避免在错误消息中拼接用户输入，防止注入式提示（如 “用户
admin'; DROP TABLE--不存在”）
最易被忽略的是日志与响应的边界混淆——开发时习惯 var_dump 调试，上线后忘记删；或错误码设计没区分“可重试”和“需人工介入”，导致前端无限轮询失败接口。合规不是加一层 try-catch 就完事，而是每条错误路径都要经过脱敏、分类、分级三道关。
