PHP上传大文件到GridFS内存溢出时，必须用fopen('rb')传资源句柄给uploadFromStream()实现流式分块上传，禁用file_get_contents或uploadFromFilename等全量加载方式。
PHP上传大文件到GridFS时内存溢出怎么办
直接用 fopen() 读完整个大文件再传给 GridFSBucket::uploadFromStream()，PHP进程会把整个文件加载进内存，1GB文件就占1GB内存，很容易触发 Fatal error: Allowed memory size exhausted。必须流式处理。
- 用
fopen($filepath, 'rb')打开文件，但不要fread()全部内容 - 调用
GridFSBucket::uploadFromStream()时，直接传入资源句柄（resource），MongoDB驱动会自动分块读取、分块写入 - 确保 PHP 的
memory_limit至少留出 16–32MB 给脚本自身逻辑，不是靠它扛文件体积 - 如果用
cURL或file_get_contents()中转，一定失败——它们不支持流式上传到 GridFS
上传时如何设置文件名、MIME类型和元数据
GridFS 不是黑盒存储，uploadFromStream() 的第三个参数是选项数组，必须显式传 filename 和 contentType，否则文件在 GridFS 中无法被正确识别或下载。
-
filename必须设，否则find()查不到（GridFS 默认按filename字段索引） -
contentType推荐设，浏览器下载时依赖它决定打开方式；不设默认为application/octet-stream - 自定义字段（如
user_id、upload_time）加到metadata数组里，会存进files集合的对应文档 - 示例：
$options = [ 'filename' => 'report.pdf', 'contentType' => 'application/pdf', 'metadata' => ['user_id' => 123, 'source' => 'web'] ];
上传后怎么安全获取文件下载链接或流式响应
GridFS 没有“URL”概念，所谓“链接”只是你用 _id 或 filename 构造的路由参数，后端需手动查、流式输出。别试图让 Nginx 直接代理 GridFS 文件。
- 用
GridFSBucket::find()查文件，推荐按filename查（注意可能重名，生产环境建议用唯一ID做文件名前缀） - 查到后用
GridFSBucket::openDownloadStream()获取流，再用fpassthru()输出，别用stream_get_contents()全部读进内存 - 务必设置
Content-Type和Content-Disposition响应头，否则浏览器可能乱码或自动保存为 .bin - 记得调用
ob_end_clean()清空输出缓冲，避免 header 冲突
为什么用 uploadFromStream() 而不用 uploadFromFilename()
uploadFromFilename() 看似简单，但它内部会调用 file_get_contents()，等价于把整个文件读进内存再上传——和手动 fread() 没本质区别，对大文件毫无优势。
立即学习“PHP免费学习笔记（深入）”；
- 只有
uploadFromStream()支持真正流式上传，底层调用 C 驱动的 chunked write，每块默认 255KB，可控且内存友好 -
uploadFromFilename()适合小配置文件、图标等 KB 级文件，别碰 MB 以上文件 - 如果你已经用了
uploadFromFilename()并遇到超时，不是加set_time_limit()就能解决的，根本问题是内存模型不对
maxUploadSizeBytes（默认 100MB）和 Nginx 的 client_max_body_size，这两个值必须协同调大，且 PHP 的 upload_max_filesize 和 post_max_size 也要同步匹配。差一个环节，前端选了200MB文件，后端连请求体都收不全。 
