php项目需严格管理composer.lock、分支命名体现php版本、用git hooks拦截调试代码、慎用submodule、注意opcache配置。
git commit 前必须检查 composer.lock 是否更新
PHP 项目依赖变动不等于 composer install 就完事——composer.lock 文件才是 Git 里真正该跟踪的“依赖快照”。漏提交它，协作时别人 composer install 装出来的包版本可能和你本地完全不一致，连 vendor/autoload.php 都可能报错。
实操建议：
- 每次运行
composer require、composer update或删改composer.json后，立刻确认composer.lock有被修改（git status看一眼） - 别把
vendor/加进 Git——它该在.gitignore里，且确保没被意外 track 过（用git rm -r --cached vendor清理历史缓存） - CI 流水线里必须用
composer install --no-dev（生产环境）或--no-interaction（自动化场景），否则卡住
分支命名要体现 PHP 版本与部署环境约束
PHP 不是纯前端，不同分支跑的 PHP 大版本（7.4 / 8.1 / 8.2）和扩展（如 ext-gd、ext-opcache）可能不兼容。光叫 feature/login 容易让人忽略底层运行时差异。
实操建议：
- 主干分支名带上最低 PHP 要求，比如
main-php81、legacy-php74，而不是全项目统一叫main - 预发分支（
staging）要和线上环境 PHP 版本、php.ini关键配置（memory_limit、opcache.enable）严格对齐 - 合并前用
php -v和php -m | grep gd快速验环境，比等 CI 报Call to undefined function imagecreatefrompng()强
git hooks 防止提交带 var_dump() 或 die() 的调试代码
PHP 调试残留（尤其是没删干净的 var_dump()、print_r()、die()）进主干，轻则接口返回乱码，重则直接 500。Git pre-commit hook 是最后一道防线。
实操建议：
- 在
.git/hooks/pre-commit里加一行：git diff --cached --name-only | xargs grep -l "var_dump|die(.*);.*$" 2>/dev/null && echo "ERROR: debug code found" && exit 1 - 别依赖 IDE 自动清理——不同人用不同编辑器，规则不统一；hook 是强制的
- 如果项目用了 Psalm/PHPStan，hook 里顺手跑
phpstan analyse --no-progress，比等 PR 评论里被指出类型错误更省时间
submodule 管理第三方 PHP 包不如用 Composer，但有个例外
绝大多数 PHP 第三方库该走 Composer，不是 Git submodule。唯一值得破例的是你自己维护的私有 SDK（比如 mycorp/payment-sdk），且它本身是独立可测试的 PHP 包，又不想搭私有 Packagist。
实操建议：
- 用
git submodule add -b main git@github.com:mycorp/payment-sdk.git lib/payment-sdk，注意指定分支（不是 tag），方便后续git submodule update --remote - 务必在项目根目录的
composer.json里加 autoloader 映射："autoload": { "psr-4": { "MyCorp\Payment\": "lib/payment-sdk/src/" } }，否则composer dump-autoload不认 - CI 构建时记得加
git submodule update --init --recursive，否则lib/payment-sdk/是空文件夹
最常被跳过的细节：PHP 的 opcache.revalidate_freq 在开发机设成 0 很爽，但上线后忘了调回 60，结果改了代码不生效，第一反应却是怀疑 Git 没 pull 对——其实只是 OPcache 没刷新。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
