GridFS本身不提供预签名URL功能，必须由应用层手动实现token签名逻辑，且签名必须绑定fileId、filename和过期时间，否则容易被重放或挪用。
直接给结论：GridFS 本身不提供预签名 URL 功能，必须由应用层手动实现 token 签名逻辑，且签名必须绑定 fileId、filename 和过期时间，否则容易被重放或挪用。
为什么不能直接用 GridFS 的 fileId 做公开下载链接
GridFS 的 fileId（如 ObjectId 字符串）本质是数据库主键，无访问控制、无时效性、无校验能力。暴露后可被任意请求反复下载，也无法区分权限或限制有效期。
常见错误现象：
- 前端把
/download/65a1b2c3d4e5f67890abcdef直接写死在页面里，爬虫批量刷导致带宽暴涨 - 用户分享链接后长期有效，文件已删但链接仍返回 404 或旧内容（因 chunks 残留）
- 攻击者把一个合法
fileId拼到另一个filename上，绕过业务级文件归属判断
如何生成带签名和过期时间的临时链接
核心是构造一个服务端可控、客户端不可伪造、且含明确失效点的 URL。推荐使用 HMAC-SHA256 签名，参数必须包含：fileId、filename、exp（Unix 时间戳）。
实操建议：
- 签名密钥必须从环境变量读取（如
process.env.GRIDFS_TOKEN_KEY），禁止硬编码 -
filename必须参与签名——防止 token 被复用于其他同名文件（比如用户上传两个report.pdf） - 过期时间
exp用秒级时间戳（Math.floor(Date.now() / 1000) + expiresInSec），别用毫秒，避免前后端时间差导致误判 - 生成的 URL 路径建议统一走
/files/:fileId，而非/download/:fileId，便于后续加网关鉴权层
示例函数（Node.js）：
const crypto = require('crypto');
const secret = process.env.GRIDFS_TOKEN_KEY;
function generatePresignedUrl(fileId, filename, expiresInSec = 3600) {
const exp = Math.floor(Date.now() / 1000) + expiresInSec;
const payload = `${fileId}:${filename}:${exp}`;
const signature = crypto
.createHmac('sha256', secret)
.update(payload)
.digest('hex');
return `/files/${fileId}?filename=${encodeURIComponent(filename)}&exp=${exp}&sig=${signature}`;
}
后端验证签名时最容易漏掉的三件事
生成只是第一步，验证逻辑出错会让整个机制形同虚设。
关键检查点：
- 收到请求时，先校验
exp是否已过期（exp < Math.floor(Date.now() / 1000)），过期直接 403，不查库 - 重新拼
payload时，filename必须用decodeURIComponent()还原，否则 URL 编码空格（%20）会导致签名不匹配 - 查 GridFS 前，必须用
new ObjectId(req.params.fileId)转换 ID 类型；传入字符串不报错但查不到，静默失败 - 最终比对签名时，用
crypto.timingSafeEqual()（Node.js 16+）或恒定时间字符串比较，防侧信道攻击
前端拿到链接后怎么触发下载而不是预览
浏览器是否下载取决于响应头，不是 URL 后缀或路径。即使链接指向 PDF，也要靠 Content-Disposition 控制行为。
后端路由中必须显式设置：
res.setHeader('Content-Type', file.contentType || 'application/octet-stream')res.setHeader('Content-Disposition', `attachment; filename="${encodeURIComponent(filename)}"`)- 流式传输：用
bucket.openDownloadStream(fileId).pipe(res)，不要toArray()或read()全部加载进内存
注意：filename 是从 query 参数取的（已签名校验过），不是从 GridFS files 文档里读的——防止攻击者篡改 URL 中的 filename 导致 header 注入（如传入 name="x.pdf%0AContent-Length:0"）。
真正难的不是签名算法，而是确保每一步都做类型校验、编码还原、恒定时间比对和流式响应——少一环，临时链接就退化成裸 ID 链接。
