Nginx 不提供定时清理静态文件功能，需在操作系统层面结合脚本与 crontab 实现，核心是依据引用关系识别冗余文件（如过期 contenthash 资源、旧版本目录、临时文件等），并通过 find 精准删除，同时配合构建流程与命名规范确保安全。
Nginx 本身不提供定时清理静态文件的功能，它只负责按配置分发文件。所谓“定时清理冗余静态文件”，实际是指对构建生成或手动上传的原始静态资源（如 /var/www/static/ 或 /data/assets/）进行周期性去重、过期或无用文件清理。这必须在操作系统层面结合脚本与调度工具实现，同时需与前端构建策略协同，避免误删正在使用的资源。
明确哪些文件算“冗余”
不是所有旧文件都需要删——关键看是否还有引用。常见冗余场景包括：
- 构建产物中带 contenthash 的旧 JS/CSS 文件（如
app.abc123.js已被app.def456.js替代，且 HTML 中不再引用前者） - 多版本打包残留（如
v1.2.0/、v1.3.0/目录中仅最新版被 Nginx location 指向） - 临时上传、测试用但未归档的图片或文档（如
test_20250812.png、backup_old.zip） - 日志类静态输出（如
/static/reports/2025-01/已超过保留周期）
用 find + 时间/命名规则精准识别冗余文件
推荐在目标目录内执行，避免跨路径误操作：
- 清理 90 天前的普通静态文件（排除
.git、README.md等保护项）：find /var/www/static -type f -mtime +90 ! -name "*.git*" ! -name "README.md" -delete
- 删除不含当前哈希值的旧构建文件（假设当前有效哈希为
xyz789，且文件名含哈希）：find /var/www/static/js -type f -name "app.*.js" ! -name "app.xyz789.js" -delete
- 清理空子目录（常因批量删除文件后残留）：
find /var/www/static -depth -type d -empty -delete
写成可调度的清理脚本并加入 crontab
创建 /usr/local/bin/clean-static.sh，内容示例：
#!/bin/bash
STATIC_ROOT="/var/www/static"
CURRENT_HASH=$(grep -o 'app\.[a-z0-9]\{6,8\}\.js' /var/www/index.html | head -1 | sed 's/app\.//; s/\.js//')
echo "[$(date)] Starting cleanup in $STATIC_ROOT"
# 仅删 js/css 中非当前哈希的文件
find "$STATIC_ROOT/js" "$STATIC_ROOT/css" -type f \( -name "app.*.js" -o -name "main.*.css" \) ! -name "app.${CURRENT_HASH}.*" ! -name "main.${CURRENT_HASH}.*" -delete 2>/dev/null
# 清理 120 天前的图片（保留近期运营图）
find "$STATIC_ROOT/img" -type f -mtime +120 -name "*.png" -o -name "*.jpg" -delete 2>/dev/null
echo "Cleanup done."赋予执行权限并加入定时任务：
chmod +x /usr/local/bin/clean-static.sh # 每月1日凌晨2点执行 echo "0 2 1 * * root /usr/local/bin/clean-static.sh >> /var/log/static-cleanup.log 2>&1" | sudo tee -a /etc/crontab
配合构建流程，从源头减少冗余
- CI/CD 发布时，先备份当前哈希清单（如
current-hashes.json），再上传新资源，最后运行清理脚本比对删除 - 使用统一入口管理静态资源路径（如通过
nginx.conf中的map指令动态映射location /static { alias /var/www/static/$version/; }），让旧版本目录天然“下线” - 对上传类静态资源（如用户头像、附件），启用独立目录+时间戳子目录（
/upload/2026/06/），配合max_age自动归档或迁移
本质上，定时清理不是 Nginx 的功能延伸，而是运维规范的一部分。重点不在“怎么删”，而在“删什么”和“什么时候删”——依赖清晰的文件命名约定、可追溯的发布记录和最小权限的操作机制。
