composer版本约束语义严格：^1.2.3≥1.2.3＜2.0.0，^0.2.3≥0.2.3＜0.3.0，~1.2.3≥1.2.3＜1.3.0；php版本须写在根require中才生效；未提交composer.lock则所有约束失效。
写错一个符号，composer install 就可能装上没测过的版本，线上直接报错——这不是偶然，是约束语义被误读的必然结果。
^ 和 ~ 的数学等价式必须手写出来才记得住
它们不是“大概兼容”，而是有明确定义的区间表达式，且主版本是否为 0 会彻底改变行为：
-
^1.2.3≡>=1.2.3 （主版本非 0，允许次版本升级） -
^0.2.3≡>=0.2.3 （主版本为 0，只允许补丁升级） -
~1.2.3≡>=1.2.3 （锁死次版本号，只放行修订号） -
~1.2≡>=1.2.0 （等价于 <code>~1.2.0，但语义更模糊）
别凭感觉换用。比如你只在 symfony/console v6.3.x 上完整测试过，却写了 "^6.3.0"，那 composer update 可能升到 6.4.0 —— 而 "~6.3.0" 才真正卡死在 6.3.x 区间。
PHP 版本约束写在 require 里才生效
config.platform.php 是模拟环境用的，它不会阻止你在 PHP 7.4 上装一个声明要 ^8.1 的项目。真要拦住，必须这样写：
{
"require": {
"php": "^8.1"
}
}
注意三点：
- 必须写在根级
require，不是require-dev；否则 CI 构建时可能跳过校验 -
^8.1等价于>=8.1.0 ，能安全接受 <code>8.2.x、8.3.x，适合大多数场景 - 如果项目用了只读属性或
match表达式，就该写"php": "^8.2"，别为了“兼容”降级约束
常见失效：Docker 多阶段构建中，composer install 运行在构建机本地 PHP 下，而非目标镜像环境 —— 这时约束形同虚设。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
7.4.* 是非法写法，composer 会静默忽略或报错
Composer 不支持通配符 * 出现在稳定版版本字符串末尾。下面这些都错：
-
"php": "7.4.*"→ 报错：Your requirements could not be resolved -
"monolog/monolog": "2.*"→ 语法合法但语义危险，等价于^2.0.0，可能升到2.10.0
正确替代方案：
- 要匹配所有
7.4.x→ 写"php": "^7.4"或"php": ">=7.4.0 - 要锁定精确版本 → 写
"monolog/monolog": "=2.8.0"（单等号）或"==2.8.0"（双等号更稳妥）
顺带一提："2.8.*" 虽然被部分人用，但它等价于 ~2.8.0，不如后者语义清晰，CI 工具扫描也更难识别。
composer.lock 没提交，composer.json 里的所有约束都只是纸上谈兵
一旦 composer.lock 存在，composer install 就完全忽略 composer.json 中的 ^ 或 ~，只按 lock 文件里记录的版本安装。这意味着：
- 团队里有人删了 lock 文件再
install，就会按当前约束重新解析依赖图 —— A 装symfony/http-foundation v6.3.0，B 装v6.3.8，C 直接上了v6.4.0 - CI 流水线若没拉取最新 lock 文件，构建产物和本地开发环境就不一致
- 修复 bug 后想回退到某个已知稳定组合？没有 lock 文件，光靠
composer.json根本做不到
最易被忽略的一点：lock 文件只记录「当时解析出的版本」，不记录「为什么选这个版本」。遇到 Your requirements could not be resolved，得靠 composer why-not 和 composer depends 去查冲突源头，而不是盯着 composer.json 猜。
