support 字段应写真实有效的 GitHub issues 地址、可 clone 的源码地址、专用安全邮箱；replace 须严格兼容原包，provide 更适合声明能力；版本约束需精确匹配 LTS 或补丁策略；archive 配置须用正则排除、验证 dist 包可离线运行。
Composer 包的 support 字段写什么才真正有用
很多人把 support 当成填空项，随便写个 GitHub 链接完事。但实际中，用户遇到问题第一反应是翻 composer.json 里的 support，它直接决定求助路径是否畅通。
这个字段不是装饰，而是维护响应链的起点。写得模糊，就会让 PR 被忽略、issue 沉底、安全报告石沉大海。
-
issues必须指向真实开启且有人看守的 issue tracker（比如https://github.com/vendor/package/issues），不能是组织主页或已归档仓库 -
source要能git clone，不能是带重定向的短链接或文档页；CI/CD 流水线依赖它自动拉取源码 -
email建议用专用别名（如security@vendor.com），避免绑定个人邮箱——人一离职，安全通报就断了 - 不推荐只写
irc或forum，PHP 社区主流支持渠道仍是 GitHub + 邮件列表，冷门入口等于没写
用 replace 和 provide 管理包的“身份替换”
当你要废弃一个包、合并多个包，或提供兼容层时，replace 和 provide 是 Composer 唯一能干预依赖解析逻辑的机制。错用会导致依赖冲突、安装失败，甚至静默降级到错误版本。
典型误用：用 replace 声明自己“替代”另一个包，却没确保 API 兼容——结果下游项目运行时报 Class not found。
-
replace用于声明“我完全取代某个包”，必须版本号对齐原包的兼容范围（例如"monolog/monolog": "^2.0"），且实际代码能跑通原包所有公开接口 -
provide更安全，适合声明“我提供了某能力”，比如"psr/log-implementation": "1.0.0"，它不移除原包，只参与虚拟包解析 - 不要在稳定版中用
replace指向 dev 分支或未发布版本，Composer 会拒绝安装——它只认已 packagist.org 注册的版本号 - 执行
composer update后检查composer show输出，确认被replace的包确实没出现在依赖树里
版本约束写错，composer update 就会绕过你的维护计划
你定了 LTS 版本只修 bug、每半年发一个 feature 版，但若 composer.json 里写的是 "^1.0"，用户装完就自动升到 1.9，根本不会停在你承诺的 1.5 安全基线。
版本约束不是语义化占位符，它是 Composer 解析器的指令集，直接影响下游能否按你的节奏更新。
- 对主维护分支（如
2.x），用"~2.3.0"限定只接受2.3.*补丁更新，明确阻断2.4.0的自动升级 - 若提供长期支持版本，建议单独打标签并用完整版本号约束（如
"2.3.7-lts"），再配合minimum-stability: stable锁死 - 避免在
require中使用*或dev-前缀，它们会让composer update忽略stability配置，拉下未测试的快照版 - 运行
composer prohibits vendor/package可查清哪个依赖强行抬高了版本要求——常是间接依赖在搞鬼
archive 配置和 dist 发布脚本决定别人能不能离线装你的包
很多团队内网用 Composer，依赖必须走私有镜像或本地 tarball。如果你没配 archive 或发布的 dist 包缺 autoload 映射、漏 vendor/ 外文件，他们 composer install --no-dev 会直接报错。
这不是“发布后才要管”的事，而是打包那一刻就定死了下游部署体验。
-
archive下的exclude别写"tests/*"这种 shell 模式，Composer 只认preg_match风格正则（如"#/tests/.*#"） - 发布前用
composer archive --format=zip --dir=dist/生成 tarball，解压后手动跑一次php -d extension=... vendor/autoload.php，验证类是否可加载 - 若包含二进制命令（如
bin/mytool），必须在composer.json中声明"bin": ["bin/mytool"]，否则composer install不会软链到vendor/bin/ - 私有仓库启用
artifact模式时，确保每个.zip文件名含完整版本号（如package-1.2.3.zip），否则 Composer 无法匹配版本约束
维护策略最易被跳过的环节，是验证“别人不用 git clone、不用网络，只靠你发的 dist 包，能不能完整跑起来”。这点不卡死，所有版本计划都是纸面约定。
