Composer本身不处理Bug报告，提交入口是GitHub仓库；需先用diagnose、clear-cache和最小化复现确认是否真为Bug；提交时必须提供Composer/PHP版本、完整命令输出、最小composer.json四类信息，并严格按模板填写。
composer 本身不处理 Bug 报告的提交逻辑——它只是依赖管理工具，真正接收、分类、响应问题的是其上游 issue 平台（GitHub）和维护者团队。你提交的不是给 composer 命令，而是给 <a href="https://www.php.cn/link/dd0bc433d9a5a097cf08a42aeeb14df2">https://www.php.cn/link/dd0bc433d9a5a097cf08a42aeeb14df2</a>。
怎么确认这真是 Composer 的 Bug，而不是配置或环境问题
很多“Bug”其实是本地环境干扰导致的，比如缓存污染、PHP 版本不兼容、权限错误或自定义插件冲突。
- 先运行
composer diagnose：它会检查常见陷阱，如可写目录、HTTPS 支持、git 配置等 - 清空缓存再试：
composer clear-cache，避免旧包元数据干扰 - 用最小化复现：新建空目录，只执行
composer init -n+ 一行require，看是否还能触发 - 关掉所有第三方插件（检查
composer.json中的plugins或全局composer.json）
如果问题消失，说明不是 Composer 核心问题；如果稳定复现，才进入下一步。
提交前必须收集的 4 类关键信息
没有这些，维护者大概率会直接关闭 issue——这不是态度问题，是效率门槛。
-
Composer 版本：运行
composer --version，注意区分Composer version 2.7.7和2.7.7 (stable)，后者才是正式发布版 -
PHP 版本：用
php -v，尤其注意是否启用了opcache.enable_cli=1（它会影响composer install行为） -
完整复现命令 + 输出：粘贴从
cd your-project开始的全部终端操作，包括错误信息（不要截图，要纯文本），尤其是带堆栈的RuntimeException或JsonDecodingException -
最小化
composer.json：删掉所有无关字段，只留name、type、出问题的require，并确认该文件能 100% 复现问题
漏掉任意一项，都可能让 issue 卡在 needs-more-info 状态数周。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
GitHub 提交时的实操细节
去 https://www.php.cn/link/dd0bc433d9a5a097cf08a42aeeb14df2/new/choose，选 “Get started” 而不是 “Open a regular issue”，这样会自动套用官方模板。
- 标题别写“Composer 不工作了”，要像这样：
composer update fails with "Could not parse version constraint" on PHP 8.3 when using caret range - 在
Environment小节填入上面收集的四类信息，每项单独成段，别塞进一段里 - 把错误输出整个放进
```代码块，别加省略号（…）或手动删减行号——维护者靠行号定位源码 - 如果涉及私有仓库或认证，不要贴 token 或密码，改用占位符如
https://token:***@myrepo.example.com
提交后留意 GitHub 自动回复：它会打上 bug 或 question 标签，并可能要求你补日志。这时候别等，立刻响应——沉默超过 7 天，issue 很可能被自动关闭。
support.issues 字段填错会导致你的报告没人看
如果你是包作者，想让别人更容易给你提 issue，composer.json 里的 support.issues 必须是完整可访问的 URL，且指向 Issues 列表页（不是模板、不是 README、不是登录页）。
- ✅ 正确：
"issues": "https://github.com/myorg/mypackage/issues" - ❌ 错误：
"issues": "./issues"（相对路径，Packagist 解析失败） - ❌ 错误：
"issues": "https://github.com/myorg/mypackage/blob/main/.github/ISSUE_TEMPLATE/bug.md"（这是模板文件，不是 issues 主页）
这个字段虽不影响安装，但 Packagist 页面的 “Support” 区域就靠它展示。用户点不到入口，就不会给你提 report——再严重的 bug 也等于不存在。
