必须手动调用send()，因ThinkPHP6仅在控制器return后自动调用，中间件等场景需显式调用；send()后不可再修改响应，且会立即输出并刷新缓冲区。
手动调用 send() 是必须的，否则响应不会真正发出——这不是副作用，而是 ThinkPHP 6 的明确设计行为。
为什么控制器里 return 就行，中间件里却必须手动 send()
ThinkPHP 6 的 response() 返回的是一个响应对象，框架只在控制器方法的 return 语句之后自动调用 send()；但在中间件、事件监听器、钩子或 CLI 命令中，这个自动机制不存在。你调用 response()->json(['code'=>0]) 后如果不跟 ->send()，HTTP 响应体就是空的，curl 或 Postman 看到状态码 200 但 body 为空。
- 控制器内：直接
return response()->json($data)安全，框架兜底 - 中间件里：
response()->json($data)->send()缺一不可 - 调用
send()后再执行echo、var_dump()或任何输出，会触发headers already sent错误 - 同一请求生命周期中多次调用
send()会报错（第二次起 headers 已发送）
send() 调用后不能再修改响应内容
send() 会立即写入 HTTP 头和响应体，并刷新输出缓冲区。一旦执行，后续对响应对象的修改（比如再调用 header()、cookie()、withCookie()）全部失效。
- 错误写法：
response()->json($data)->withCookie('a', 'b')->send(); cookie('c', 'd');—— 第二个 cookie 不会生效 - 正确顺序：所有 header / cookie / content 设置必须在
send()之前完成 - 若需动态判断是否发送，建议先构建响应对象，最后统一
->send()，不要分段操作
文件下载场景下 send() 的特殊风险
文件下载接口如果用了 response()->download() 或 raw() + 手动 header，send() 触发前若有任何前置输出（空格、BOM、echo、错误日志），会导致 Content-Transfer-Encoding 失效，浏览器可能无法识别为文件而直接渲染乱码。
立即学习“PHP免费学习笔记（深入）”；
- 确保入口文件（如
public/index.php）无 BOM 和多余空白 - 关闭调试模式下的
debug输出或异常堆栈直出（尤其在 CLI 下） - 大文件推荐用
response()->stream()+ob_end_clean()配合send()，避免内存溢出 -
send()不会自动 exit 或 die，但下载完成后继续执行可能引发意外输出，建议显式exit或die
最容易被忽略的一点：在 Log::listen() 这类全局钩子里调用 response() 并 send()，会导致日志记录和 HTTP 响应混在一起——因为钩子可能在响应已部分发送后才触发。这种交叉调用没有回滚机制，结果不可预测。
