force_download函数仅限Web环境控制器中使用，依赖HTTP上下文，CLI调用会报错；需手动处理中文文件名编码、临时文件清理，并注意大文件内存占用及兼容性问题。
force_download函数只能用于HTTP响应，不能在CLI环境调用
这个函数本质是设置一堆HTTP头（Content-Disposition、Content-Length等）然后把文件内容直接输出到响应体，所以它依赖完整的Web服务器上下文。你在命令行里跑CI脚本时调用force_download，会直接报错或静默失败——因为没有$_SERVER['REQUEST_METHOD']，也没有可写入的php://output流（或者被重定向了）。
- 常见错误现象：
Cannot modify header information - headers already sent或完全没反应，浏览器卡住 - 使用场景：仅限控制器中处理用户发起的下载请求，比如“导出报表”按钮点击后
- 参数差异：第二个参数
$data可以是字符串（内容）、资源句柄（如fopen()返回值），但不能是数组或对象；如果是路径，得确保PHP有读取权限 - 性能影响：大文件会一次性读入内存（除非你传入资源句柄并配合
fpassthru()），50MB以上建议改用readfile()+ 手动设头
中文文件名乱码？必须手动处理Content-Disposition头
force_download默认只对英文文件名做urlencode，遇到中文会直接塞进filename="xxx"字段，导致Chrome/Firefox解析失败，下载后变成download.bin或空文件名。
- 解决办法：别直接传中文名给
force_download，先自己构造兼容的Content-Disposition头 - 实操建议：用
mb_convert_encoding($filename, 'UTF-8', 'auto')统一编码，再按RFC 5987格式拼接，例如Content-Disposition: attachment; filename*=UTF-8''%E6%8A%A5%E8%A1%A8.xlsx - 容易踩的坑：PHP内置的
rawurlencode()对中文编码结果和浏览器预期不一致，别偷懒直接套用；IE11以下还得额外提供filename兼容字段
force_download不会自动清理临时文件
如果你生成的是临时CSV/ZIP（比如用tempnam()创建），force_download只负责输出，不关心文件生命周期。下载完文件还留在/tmp目录下，磁盘迟早爆掉。
- 使用场景：导出日志、批量生成压缩包、动态渲染PDF后下载
- 实操建议：下载前用
register_shutdown_function()注册清理回调，或者更稳妥地——用ob_start()捕获输出，把内容存成变量再unlink()，最后echo $content - 参数差异：如果传入的是字符串而非路径，
force_download根本不会碰文件系统，这时候清理逻辑要你自己控制 - 兼容性影响：某些共享主机禁用
register_shutdown_function，此时只能靠定时脚本或记录日志+人工清理
替代方案比硬刚force_download更可靠
CI3的force_download封装太死，不支持断点续传、不支持流式传输、不支持自定义MIME类型（比如application/vnd.openxmlformats-officedocument.spreadsheetml.sheet），真要稳定交付，不如绕过它。
- 实操建议：用原生PHP组合
header()+readfile()，控制粒度更高 - 示例：
header('Content-Type: application/vnd.ms-excel');<br>header('Content-Disposition: attachment; filename="report.xls"');<br>header('Content-Length: ' . filesize($file_path));<br>readfile($file_path); - 容易踩的坑：漏掉
exit或die，后续代码继续执行，可能污染响应体；CI的输出缓存（Output class）也可能拦截这些头，得先$this->output->reset()
实际项目里，最麻烦的不是怎么调用force_download，而是它把“设头”和“输出”绑得太紧，一旦需要加鉴权、限速、日志埋点，就得拆开重写——这时候别硬撑，换原生方案反而省时间。
