不该提交 vendor/ 目录，因其可由 composer install 基于 composer.lock 精确还原；vendor/ 含平台相关二进制文件，易致环境不一致；.gitignore 应含 /vendor，误提交后用 git rm -r --cached vendor 清除。
git 该不该提交 vendor/ 目录
不该。99% 的 PHP 项目都不该把 vendor/ 提交进 git，否则会污染历史、拖慢克隆、引发权限和路径冲突。
根本原因：依赖是可再生的，composer install 能从 composer.lock 精确还原；而 vendor/ 里包含大量二进制、平台相关文件（比如 ext-redis 编译产物），不同开发机或 CI 环境下内容不一致。
-
.gitignore里必须有/vendor（开头加/防止子目录误匹配） - 如果已误提交过，用
git rm -r --cached vendor清除索引，再 commit - CI 流程中应运行
composer install --no-dev（生产环境）或--no-interaction（自动化场景）
composer.lock 必须提交，且要常更新
composer.lock 是依赖的“快照”，它锁定了每个包的具体版本、哈希值和安装路径。没它，composer install 就退化成 composer update，结果不可控。
常见错误现象：composer install 报错 “Package not found” 或 “Your requirements could not be resolved”，往往是因为本地 composer.lock 和远程不一致，或有人漏提交 lock 文件。
- 每次执行
composer require、composer remove或composer update后，composer.lock都会变更，必须连同composer.json一起 commit - 团队协作时，禁止直接改
composer.json后不跑composer install—— 这会导致 lock 文件未更新，别人拉代码后环境不一致 - 若需临时跳过 lock（极少数调试场景），显式加
--ignore-platform-reqs，但别把它写进 CI 脚本
不同环境如何安全地管理 dev-dependencies
开发依赖（如 phpunit、larastan）只在本地和 CI 中需要，生产环境必须排除。靠 --no-dev 控制，不是靠删配置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
容易踩的坑：有人把测试工具写进 require 而非 require-dev，导致生产部署时多装一堆无用包，甚至引入安全风险。
-
composer require --dev phpunit/phpunit才会写入require-dev；漏掉--dev就进require了 - CI 脚本中明确用
composer install --no-dev，避免意外加载开发依赖 - 用
composer show --dev可快速确认当前已装的 dev 包有哪些 - 某些私有包若同时被 dev 和 prod 引用，建议拆分成两个包，或用
autoload-dev控制自动加载范围
git tag 和 composer version 怎么对齐
Composer 本身不管理发布版本号，version 字段只是元信息。真正起作用的是 git tag —— 尤其当包被其他项目 require 为 "my/pkg": "^1.2" 时，Composer 从 packagist 或私仓拉取的正是对应 tag 的代码。
典型混乱场景：手动改了 composer.json 里的 "version": "1.2.1"，但没打 git tag，结果 packagist 同步失败，别人 composer update 拉不到新版本。
- 发布前先
git tag v1.2.1，再git push --tags - 私有包托管在 GitLab/GitHub 时，确保仓库 URL 在
composer.json的repositories里配置正确，且支持 dist 方式（即能走 zip 包下载） - 用
composer show my/pkg查看实际安装版本，它显示的是 tag 名，不是composer.json里的version - 如果用了
path类型仓库（比如本地开发时），记得上线前切回正式源，否则部署会失败
最常被忽略的一点：lock 文件里记录的是包的完整 dist URL 和 SHA256，一旦你改了私仓地址或删了某个 tag，composer install 就会卡住或报 hash mismatch —— 这时候不是重生成 lock，而是得先恢复远端状态。
