PHP项目中不应将二进制文件（如PDF、JPG、vendor/composer.phar、构建产物dist/等）纳入Git，因其拖慢操作、无法diff、易冲突、浪费空间；应交由CDN、对象存储等外部服务管理，代码中仅保留URL或哈希等元信息。
PHP 项目里不该把二进制文件放进 Git
直接说结论：PHP 本身不提供版本控制能力，git 才是实际管理者；而二进制文件（如 pdf、jpg、vendor/composer.phar、node_modules 打包产物）一旦纳入 git，会迅速拖慢克隆、拉取速度，且无法 diff、易冲突、浪费仓库空间。
常见错误现象：git status 显示大量二进制变更却看不出改了啥；git push 卡住十几分钟；CI 构建因大文件超时失败。
- 所有二进制资产应走外部存储：CDN、对象存储（如 S3、MinIO）、或私有文件服务器
- PHP 代码里只保留元信息：路径、URL、哈希值（如
$file_url = 'https://cdn.example.com/uploads/report_v2.1.pdf';） - 若必须本地存，用
.gitignore显式排除，例如：/public/uploads/*、/storage/app/*（Laravel 默认已配）
composer install 生成的 vendor 是二进制吗？怎么管
vendor/ 目录不是二进制文件，而是 PHP 源码+部分扩展的编译产物（如 ext-redis 的 .so 文件），但它仍不该提交到 Git。原因很实在：体积大、平台相关、可复现。
正确做法是只提交 composer.json 和 composer.lock，靠它们还原依赖：
立即学习“PHP免费学习笔记（深入）”；
-
composer install（CI/生产环境）——严格按lock安装，确保一致性 -
composer update（开发环境）——更新依赖并刷新lock，之后git add composer.lock - 若需离线安装，用
composer install --no-interaction --no-scripts+ 提前缓存~/.composer/cache
注意：composer.lock 必须提交，否则不同机器上 composer install 可能装出不同版本。
上传的用户文件（图片/PDF）怎么版本化
用户上传的文件天然不可预测、不可复现，强行用 Git 版本化等于自找麻烦。真实场景要的是「可追溯」+「可回滚」，不是 Git commit 历史。
推荐做法是结合命名策略与元数据表：
- 文件名用内容哈希 + 时间戳，如
sha256_abc123_20240520143022.jpg，避免覆盖也便于去重 - 数据库存记录：
id、original_name、stored_path、uploader_id、created_at、checksum - 需要“回滚到旧版”？不是恢复 Git commit，而是查历史记录，再把对应
stored_path的文件重新设为当前版本 - 备份策略独立制定：每日 rsync 到 NAS / 定期 dump S3 bucket 列表 + 元数据
build 产物（如 dist/、public/build/）要不要 Git 跟踪
不要。这些是构建结果，不是源码。PHP 项目中常见于混用前端工具链（Vite/Webpack）的场景，dist/ 本质和 vendor/ 一样：可再生、体积大、平台敏感。
关键判断点：能否用现有源码 + 确定命令 100% 重建它？ 如果能，就该被忽略：
- 在
.gitignore加一行：/public/build/或/dist/ - CI 流程中加构建步骤：
npm ci && npm run build，再把产出同步到 Web 根目录 - 若部署依赖本地构建产物（如无 Node 环境），那就把构建过程移进 Docker 构建阶段，而不是提交产物
最容易被忽略的一点：有些团队用 git add -f public/build/ 强行提交，只为图省事跳过 CI —— 这会让环境差异悄悄累积，某天 npm run build 输出变了，线上却还跑着旧 hash 的 JS，问题极难定位。
