composer validate仅校验json语法和字段结构，不检查包存在性、版本可解性、php兼容性或autoload路径，真正验证依赖能否安装需用--dry-run。
composer validate 只校验 JSON 语法和字段结构，不是“能装上”的保证
它告诉你 composer.json 写得像不像人话，但不关心你说的包到底存不存在、版本能不能解出来。所以常见现象是：./composer.json is valid 刚刷出来，composer install 紧接着就报 Could not find package xxx 或 Version conflict。
-
composer validate不联网，不查 Packagist，也不解析^1.2.3或dev-main这类约束是否真实可命中 - 它不会发现你把
"require"拼成"requre"（除非加--strict），也不会检查autoload里写的路径是否存在 - 私有包名如
"myorg/mylib"即使没配repositories，validate 也完全沉默——直到install阶段才炸 - PHP 版本兼容性？比如
"php": ">=7.4"在 PHP 8.2 下跑得欢，validate 照过不误，但 runtime 可能直接挂
什么时候该用 --strict？为什么默认不推荐裸跑
--strict 是唯一值得日常开启的参数，否则很多低级错误会被放过去。
- 缺
"description"、"license"这类推荐字段，默认只警告；加--strict就直接失败，防团队随意糊弄 - 多写了未定义字段（比如手误加了
"autload"或"my-config"），--strict会拦住；不加就当空气 - 误用已弃用写法（如
"dev-master"）或非 SPDX 标准 license 值（如"MIT License"而非"MIT"），--strict才报 - CI/CD 中务必带
--strict，并配合set -e或fail-fast: true，别让它“校验失败却继续往下跑”
真正暴露依赖问题的命令不是 validate，而是 --dry-run
想确认“这个配置真能装上”，必须用依赖求解器走一遍流程，而不是靠 schema 校验。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer install --dry-run：模拟安装全过程，检查包存在性、版本冲突、锁文件一致性，速度比真装快得多 -
composer update --dry-run：适合改完require后验证新依赖图是否可解 -
composer install --no-install --dry-run：更轻量，跳过下载和解压，纯做解析，CI 里推荐 - 注意：如果项目用了自定义
repositories（比如 Git URL 或 Satis），validate完全无感，只有--dry-run能验证可达性
别忽略 JSON 本身错误——这是 validate 最容易卡住的第一关
很多报错根本不是 Composer 规范问题，而是 JSON 语法翻车，比如从网页复制粘贴带了零宽空格，或末尾多逗号。
- 用
jq . composer.json快速定位行号列号错误（需先apt install jq或brew install jq） - VS Code 或 PHPStorm 打开
composer.json，看有没有高亮标红——中文引号、单引号、隐藏字符都会被揪出 -
cat -A composer.json查看不可见字符（比如^M或u200b） - 手动写 JSON 时，别省略逗号、别用注释（
//或/* */）、别漏双引号——validate遇到这些直接抛JSON decode error
真正容易被忽略的是：校验通过 ≠ 依赖能装上，也不代表 autoload 配置能正确映射类路径。JSON 合法只是第一关，后面还有三道门要过。
