ThinkPHP 5.1 定时任务处理上传文件需注意权限、路径、临时文件及校验四类问题：1. CLI 用户与Web用户权限不同，须确保运行用户对uploads目录有rwx权限；2. 统一使用ROOT_PATH等绝对路径避免相对路径失效；3. 不依赖upload_tmp_dir，只操作已move的正式文件；4. validate后必须显式判断错误并记录日志。
ThinkPHP 5.1 中定时任务与文件上传本属两个独立模块，但若在定时任务中触发文件处理（如自动下载、归档、解析上传后遗留文件等），极易因环境差异引发隐性错误。这类组合场景不报明显语法错，却常卡在权限、路径、上下文缺失或临时文件失效上——问题不是“不能做”，而是“默认不做对”。
定时任务里调用上传逻辑？先确认执行环境
CLI 模式下 PHP 的运行用户（如 www-data、root）和 Web 请求用户往往不同，而上传相关目录（uploads/、upload_tmp_dir）的写权限通常只给了 Web 用户。定时任务一跑，就卡在 move_uploaded_file() 或 $file->move() 返回 false。
- 用
whoami和ps aux | grep php查当前 crontab 执行的用户身份 - 确保该用户对目标上传目录有 rwx 权限（推荐
chown -R www-data:www-data uploads/并设chmod -R 755 uploads/） - 避免在定时任务中直接复用 Web 端的
request()->file()—— CLI 下无 $_FILES，该方法返回 null
上传后的文件，在定时任务中找不见？路径是最大陷阱
ThinkPHP 在 Web 请求中常使用相对路径如 './static/uploads'，但在 CLI 下，当前工作目录是项目根目录还是 public/？ 不同启动方式（php think xxx vs php public/index.php）基准路径不同，导致 file_exists() 判断失败或 fopen 报错。
- 统一用绝对路径：用
ROOT_PATH . 'public' . DS . 'uploads'替代 ./static/uploads - 检查
$_SERVER['DOCUMENT_ROOT']在 CLI 中为空，别依赖它 - 日志中打印
getcwd()和__DIR__，确认实际读取位置
临时文件被清空？别指望 upload_tmp_dir 持久化
PHP 上传机制会把文件暂存到 upload_tmp_dir（默认系统 /tmp），Web 请求结束后由框架 move 走；但定时任务若处理的是“已上传完成”的文件，就完全不走这个流程。如果误以为能从 upload_tmp_dir 里捞出旧分片或缓存文件——大概率已删。
立即学习“PHP免费学习笔记（深入）”；
- 定时任务处理上传结果时，只操作 已 move 到业务目录的正式文件，不要反向查找 tmp 文件
- 如需保留原始上传态，应在 Web 端上传成功后，把
$info->getSaveName()和元数据存入数据库，供定时任务按 ID 查询路径 - Linux 的 /tmp 有自动清理策略（systemd-tmpfiles），不要把业务临时文件放这里
validate 失败却不报错？静默跳过是定时任务的常态
Web 端上传失败会通过 $file->getError() 显示提示，但 CLI 下没有响应体，validate(['ext'=>'jpg']) 若不满足条件，仅返回 false，后续逻辑照常执行，容易漏掉校验环节。
- 每次调用
validate()后必须显式判断：if (!$file->validate(...)) { \think\Log::error('上传校验失败：' . $file->getError()); return; } - 避免链式调用
$file->validate(...)->move(...)，validate 失败时 move 会抛异常或返回 null，但 CLI 不捕获就静默终止 - 大小限制建议用字节值（如
1024 * 1024 * 2）而非字符串（'2M'），避免 CLI 下 ini_get() 获取不准
