用途：指导采用与运维 Release Please（googleapis/release-please 及 googleapis/release-please-action），实现由 Conventional Commit 驱动的版本递增、变更日志生成、自动创建 Release PR 以及 GitHub 打标签与发布，也可用于从手动标签/日志/版本流程迁移。
模式选择：单包模式（single-package）从仓库根产生单一版本流；manifest 模式为每个路径/包维护独立版本。若存在多个独立版本化的包，应使用 manifest 模式。
前置条件：默认分支历史中包含 Conventional Commits（fix:、feat:、!/BREAKING）；分支与工作流权限足以写入 PR 与发布；工作流在默认发布分支（main/master）上触发。推荐最小权限：contents: write、pull-requests: write，issues: write 为可选但常用。
快速开始：单包模式在 .github/workflows/release-please.yml 使用 googleapis/release-please-action@v4，在推送到默认分支时触发。manifest 模式需添加 release-please-config.json 与 .release-please-manifest.json，并在工作流中传入 config-file 与 manifest-file。
生命周期：合并 Conventional Commit PR → Release Please 打开/更新 Release PR → CI 校验 → 合并 Release PR → 动作创建标签与 GitHub Release。
迁移：停止在受管分支手动编辑变更日志与标签；manifest 模式下将 manifest 版本填充为当前已发布版本；合并首个 Release PR 并验证输出在下游工作流步骤中的使用形态。
常见失败：无 Release PR（无可发布提交、分支触发错误、autorelease 标签过期或令牌/权限不匹配）；版本递增错误（提交语义不符合约定）；缺失日志条目（压缩标题/历史非约定格式）；manifest 不匹配（包路径键与实际目录不符）；工作流链未触发（需 PAT/App 令牌行为时误用 GITHUB_TOKEN）。
护栏与核查：在 CI 强制 Conventional Commit 校验；明确发布合并负责人；monorepo 中逐个添加包路径并验证；避免在受管路径手动改标签与日志；保持 Release PR 小而可预期。核查工作流触发、权限显式设置、可发布提交后出现 Release PR、合并生成标签与发布、下游安全解析动作输出键。详见上游仓库与本地 references 目录下的 setup-examples.md、action-outputs.md、return-shapes.md、troubleshooting.md。当前资料未提供收费、价格或平台支持等细节。