PHP应只输出纯JSON，不拼接HTML或JS；必须前置设置header('Content-Type: application/json; charset=utf-8')，清空输出缓冲，用json_encode()序列化数据并检查错误，前端通过fetch获取后由JS驱动DOM更新与交互。
PHP只输出JSON，别碰DOM
PHP 的职责就是查数据库、校验参数、组装数据，然后用 json_encode() 吐出纯 JSON，不拼 HTML，不 echo script 标签，不写 inline event。一旦 PHP 开始输出 HTML 片段或 JS 逻辑，后续 JS 修改结构、绑定事件、处理状态就会失控。
常见错误现象：Notice: Undefined index 频发、JS 拿到的是带 HTML 标签的字符串而非对象、前端反复解析失败。
- 确保 PHP 脚本开头调用
header('Content-Type: application/json; charset=utf-8') - 所有输出前清空缓冲区：
ob_end_clean()，避免 BOM 或调试echo污染 JSON - 用
json_last_error()检查编码失败（比如含非 UTF-8 字符或资源类型）
JS用fetch拿数据，用dataset驱动渲染
交互触发（如按钮点击、表单提交）由 JS 发起 fetch() 请求，拿到 JSON 后用原生 DOM API 或轻量模板（如 template.innerHTML）生成结构，再通过 dataset 或 data- 属性挂载上下文，而不是靠 class 名或 DOM 位置硬匹配。
使用场景：列表加载、搜索建议、表单异步提交、分页切换。
立即学习“PHP免费学习笔记（深入）”；
- 避免用
document.querySelectorAll('.item')绑定事件——动态插入的节点不会自动生效；改用事件委托：container.addEventListener('click', e => { if (e.target.dataset.action === 'delete') { ... } }) - 服务端返回的数据字段名要和前端变量名对齐，比如 PHP 返回
['id' => 123, 'title' => 'abc']，JS 就直接解构{ id, title }，别在 JS 里做res.data[0].name这种映射 - fetch 默认不带 cookie，登录态接口需显式加
credentials: 'same-origin'
错误处理必须双向对齐
PHP 返回的 HTTP 状态码和 JSON 中的 error 字段，JS 必须同时检查。只看 response.ok 不够，400/422 错误仍可能返回成功状态码但含业务错误信息。
典型错误现象：表单提交后页面没提示、控制台静默失败、用户重复点击提交。
- PHP 端：非 2xx 响应统一设
http_response_code(400)，并保证 JSON 结构一致：['success' => false, 'message' => 'xxx', 'field' => 'email'] - JS 端：先判断
response.status >= 400，再await response.json()解析错误详情，最后定位到对应 input 显示message - 不要用
try/catch包住整个 fetch——网络失败、JSON 解析失败、字段缺失是三类不同问题，需分开响应
CSRF 和接口粒度容易被忽略
分离后接口变多，但每个请求仍需 CSRF 防护，且不能把所有操作塞进一个 /api/action.php。粒度太粗，JS 逻辑会膨胀；粒度过细，PHP 端路由和权限校验难维护。
比如删除操作，别让 JS 传 { action: 'delete', id: 123 } 到通用接口，而应定义明确路径：/api/posts/123 + DELETE 方法。
- PHP 路由层用简单 switch 或文件映射即可，不必上框架，但每个 endpoint 必须独立验证权限和 token
- CSRF token 应随初始 HTML 渲染进
<meta name="csrf-token" content="xxx">，JS 在 fetch header 中读取并携带X-CSRF-TOKEN - POST/PUT/DELETE 接口必须校验 token，GET 可不校验，但禁止在 GET 中做状态变更
最常漏掉的是 token 过期后的静默刷新机制——PHP 返回 419 时，JS 不该直接报错，而要先换 token 再重试一次请求。
