必须。小程序后端接口需返回统一结构，否则前端需冗余判断；PHP应封装通用响应函数，确保code为整数、Content-Type正确、敏感字段脱敏；登录态校验须抽象为中间件，与业务逻辑分离。
小程序后端接口必须返回统一结构吗？
必须。微信小程序的 wx.request 不会自动处理业务错误码，如果后端返回格式不一致（比如有时 {data: ...}，有时直接 {errCode: -1, msg: 'xxx'}），前端就得写一堆 if (res.data instanceof Object && !res.data.code) 这类脆弱判断——维护成本高，容易漏判。
PHP 封装通用响应函数怎么写？
核心是抽离出一个可复用的响应构造逻辑，避免每个接口都重复写 json_encode(['code'=>0, 'msg'=>'ok', 'data'=>$xxx])。推荐封装成静态方法或独立函数，关键点：
-
code字段必须为整数，微信开发者工具里部分旧版基础库对字符串 code 会解析失败 - 默认
code=0表示成功，非 0 均视为业务异常（401、403等 HTTP 状态码由框架层控制，不混进业务code） - 始终返回
Content-Type: application/json; charset=utf-8，中文不乱码 - 敏感字段如
openid、session_key不应出现在data中直接透出，需脱敏或由上层过滤
示例函数：
function apiResponse($code = 0, $msg = 'ok', $data = null, $httpCode = 200) {
http_response_code($httpCode);
header('Content-Type: application/json; charset=utf-8');
echo json_encode([
'code' => (int)$code,
'msg' => (string)$msg,
'data' => $data ?? new stdClass()
], JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
exit;
}
如何兼容登录态校验与业务逻辑分离？
小程序常见流程是「每次请求带 token 或 code → 后端解密/校验 → 再执行业务」。硬编码在每个接口里会重复且易出错。建议：
立即学习“PHP免费学习笔记（深入）”；
- 把登录态校验抽象为中间件或前置函数，例如
checkAuth()，校验失败直接调用apiResponse(-401, '登录已过期') - 校验通过后把用户信息（如
$uid、$openid）注入到后续逻辑，而不是让每个接口自己查 session 或缓存 - 不要在
apiResponse()里自动塞uid到data—— 业务接口是否返回用户信息，应由业务决定
遇到跨域、emoji、大数组序列化失败怎么办？
这些不是格式设计问题，但会直接破坏「统一接口」的可用性：
- 跨域：确保所有接口响应头包含
Access-Control-Allow-Origin: *（生产环境建议精确域名）和Access-Control-Allow-Headers: Authorization, Content-Type - emoji 报错：MySQL 字段用
utf8mb4，PHPjson_encode()加JSON_UNESCAPED_UNICODE，否则存 emoji 后返回时可能变成null或乱码 - 大数组内存溢出：避免直接
apiResponse(0, 'ok', $hugeArray)，改用分页或流式处理；必要时加@ini_set('memory_limit', '256M')（仅临时兜底）
真正难的不是定义那三个字段，而是让每个开发都记得在所有分支路径里调用 apiResponse，而不是手写 echo json_encode(...) —— 代码审查和单元测试比文档更管用。
