composer browse 命令默认打开包的 homepage 字段值，若未设置则回退至 source 地址，而非 issues 页面；仅当 composer.json 中显式声明 support.issues 时才跳转至该 url。
Composer browse 命令默认打开的是什么页面
composer browse 默认会尝试打开包的 homepage 字段值（即 composer.json 中定义的 homepage），而不是 issues 页面。如果包没填 homepage，它会 fallback 到 source（如 GitHub 仓库主页），但依然不是 /issues 路径。
常见错误现象：执行 composer browse monolog/monolog 后跳转到 https://github.com/Seldaek/monolog，而非 https://github.com/Seldaek/monolog/issues —— 这让你得手动补路径，效率低。
实际能用的前提是：包的 composer.json 显式声明了 support.issues 字段，且值为合法 URL。Composer 会优先读这个字段；没有时才退回到 homepage 或 source。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
如何让 browse 命令直接打开 Issue 页面
Composer 不支持全局配置“强制跳转 issues”，但你可以通过以下方式绕过限制：
- 手动指定 URL：运行
composer browse --show monolog/monolog 查看当前包的 support.issues 值，确认是否已设置
- 若未设置，可临时用
composer browse vendor/package --no-interaction | grep -o "https://[^[:space:]]*" 提取源地址，再手动拼接 /issues
- 更实用的做法：写一个 shell 别名，自动补全
/issues 路径（见下节）
注意：composer browse 本身不解析 GitHub/GitLab 的域名规则，它只做字符串拼接或重定向，不会智能识别 “这是 GitHub 仓库，应该加 /issues”。
用 shell 别名实现一键打开 issues 页面
在 ~/.bashrc 或 ~/.zshrc 中添加：
alias cb='composer browse --show "$1" 2>/dev/null | grep -q "support.issues" && composer browse "$1" || (composer browse "$1" --no-interaction 2>/dev/null | grep -o "https://[^[:space:]]*" | head -n1 | sed "s/$/\/issues/" | xargs open)
说明：
- 先尝试用
--show 检查是否存在 support.issues，有则直接走原命令
- 没有时，提取原始源地址（通常是 GitHub/GitLab 主页），用
sed 补 /issues
-
open 是 macOS 命令；Linux 用户请换为 xdg-open；Windows WSL 用户需额外处理浏览器调用
- 该脚本不处理 GitLab 的
/-/issues 路径差异，仅适配 GitHub 风格
为什么不能直接改 Composer 源码或插件来支持
Composer 官方明确不打算扩展 browse 的逻辑，理由是：
-
browse 定位是“快速访问项目主页”，不是“问题追踪入口”
- 不同平台 issue 路径不统一：GitHub 是
/issues，GitLab 是 /-/issues，Bitbucket 是 /issues 但需登录，自建 Gitea 可能是 /issues/new
- Composer 插件机制无法拦截或重写内置命令行为（
browse 是硬编码在 Command/BrowseCommand.php 中的）
所以别费劲找插件或 patch，shell 层面的轻量封装是最稳的选择。
composer browse --show monolog/monolog 查看当前包的 support.issues 值，确认是否已设置composer browse vendor/package --no-interaction | grep -o "https://[^[:space:]]*" 提取源地址，再手动拼接 /issues
/issues 路径（见下节）~/.bashrc 或 ~/.zshrc 中添加：
alias cb='composer browse --show "$1" 2>/dev/null | grep -q "support.issues" && composer browse "$1" || (composer browse "$1" --no-interaction 2>/dev/null | grep -o "https://[^[:space:]]*" | head -n1 | sed "s/$/\/issues/" | xargs open)说明：
- 先尝试用
--show检查是否存在support.issues，有则直接走原命令 - 没有时，提取原始源地址（通常是 GitHub/GitLab 主页），用
sed补/issues -
open是 macOS 命令；Linux 用户请换为xdg-open；Windows WSL 用户需额外处理浏览器调用 - 该脚本不处理 GitLab 的
/-/issues路径差异，仅适配 GitHub 风格
为什么不能直接改 Composer 源码或插件来支持
Composer 官方明确不打算扩展 browse 的逻辑，理由是：
-
browse 定位是“快速访问项目主页”，不是“问题追踪入口”
- 不同平台 issue 路径不统一：GitHub 是
/issues，GitLab 是 /-/issues，Bitbucket 是 /issues 但需登录，自建 Gitea 可能是 /issues/new
- Composer 插件机制无法拦截或重写内置命令行为（
browse 是硬编码在 Command/BrowseCommand.php 中的）
所以别费劲找插件或 patch，shell 层面的轻量封装是最稳的选择。
browse 定位是“快速访问项目主页”，不是“问题追踪入口”/issues，GitLab 是 /-/issues，Bitbucket 是 /issues 但需登录，自建 Gitea 可能是 /issues/new
browse 是硬编码在 Command/BrowseCommand.php 中的）真正容易被忽略的是：很多包的 composer.json 根本没填 support.issues，哪怕它在 GitHub 上明明有开启 Issues 功能——这意味着你依赖的包是否“可反馈”，其实取决于作者是否手动维护这个字段。
