应使用 ^ 约束而非 ~ 或多区间表达式，禁用通配符如 "2.*"，所有约束须基于语义化版本，通配符仅限 dev 临时使用，依赖冲突时优先放宽约束粒度而非硬指定版本。
直接写死版本号最省事，但多数项目需要兼顾兼容性与可维护性——关键在于用对约束语法，而不是堆条件。
用 ^ 而不是 ~ 或多个 >=/ 组合
语义化版本下，^1.2.3 等价于 >=1.2.3 ，但前者更简洁、可读性高，且 Composer 内部解析更高效；而 <code>~1.2.3 实际只允许 >=1.2.3 ，适用场景窄（比如强绑定小版本修复），误用会导致频繁卡在旧版无法升级。
-
^是默认推荐：适配补丁+次要版本更新，兼顾稳定性与新特性 -
~适合底层工具类库（如 parser、lexer），对 API 兼容性极其敏感 - 避免手写
>=1.0.0 =3.0.0这类多区间表达式——composer/semver的Intervals::compactConstraint()虽能合并，但解析开销翻倍，且易出错
禁止在 require 中混用约束与通配符
像 "monolog/monolog": "2.*" 或 "symfony/console": "6.4.*" 这种写法看似宽松，实则绕过 SemVer 规则，Composer 会降级为字符串匹配，失去版本逻辑判断能力。一旦上游发布 2.99.0 或 6.4.99，就可能意外引入破坏性变更。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 所有约束必须基于语义化版本格式，哪怕你想“锁死小版本”，也该用
^2.0.0+composer.lock固化 -
*通配符仅在require-dev或脚本调试时临时使用，绝不提交到生产composer.json - CI 流程中可加检查：
composer validate --strict会警告非标准约束
依赖冲突时，优先降级约束粒度而非硬指定版本
当 composer update 报错 “found x conflicts”，第一反应不应该是手动改成 "vendor/pkg": "1.5.2"，而是检查是否过度收紧了约束。例如两个包分别要求 ^2.1 和 ^2.3，其实 ^2.3 已隐含兼容 ^2.1，冲突往往来自中间某个包写了 ~2.0.0 或 >=2.0.0 这类窄区间。
- 运行
composer why vendor/pkg查清谁在施加窄约束 - 对间接依赖，用
composer update vendor/pkg --with=other/vendor:^2.3测试宽松解 - 真要锁定，改
composer.lock比改composer.json更安全——前者只影响当前项目，后者会传染给所有下游
最常被忽略的点：版本约束只是“许可范围”，真正生效的是 composer.lock 里的精确版本。约束写得再漂亮，如果 lock 文件没提交、或 CI 跑的是 install 却没校验 lock，一切优化都白搭。
