核心用法
Google Chat Messaging Skill 提供两种消息发送方式，满足不同场景需求：
1. Webhook 方式（推荐固定频道）
- 预配置频道 URL，消息以机器人身份发送
- 支持线程回复（
--thread_key），适合连贯通知流 - 无需 OAuth 握手，响应速度最快
- 配置存储在
google-chat-config.json中管理多频道
2. OAuth 方式（动态目标）
- 通过 Google Cloud OAuth 认证，可向任意空间或用户发送消息
- 支持按名称查找空间（
--space）、按 ID 直接发送（--space-id） - 自动添加 🤖 前缀标识（可用
--no-emoji关闭） - 可列出可用空间（
--list-spaces）
关键限制：Google Chat API 不支持通过邮箱创建新私信，私信需已知现有空间 ID。
显著优点
- 双模式灵活切换：Webhook 用于高频固定频道，OAuth 用于动态目标
- 线程消息支持：Webhook 支持
thread_key聚合相关消息 - 卡片消息格式：支持 JSON 卡片（标题、按钮、分区）实现富文本通知
- 官方 API 保障：依赖 Google 官方客户端库，无第三方中间件
- 代码质量过关：215 行 Python 代码结构清晰，无危险函数或硬编码密钥
潜在缺点与局限性
| 问题 | 说明 |
|------|------|
| **来源可信度 T3** | 个人开发者项目，无 GitHub 公开历史，缺乏社区审查 |
| **OAuth Token 存储风险** | Token 保存为本地文件，未显式设置 600 权限，可能被同机其他用户读取 |
| **输入验证不足** | `thread_key` 直接 URL 拼接，未严格校验字符白名单 |
| **无开源许可证** | 未指定 MIT/Apache 等许可证，责任边界不明 |
| **私信限制** | 无法通过邮箱主动发起新私信，需预存在对话空间 |
| **日志级别单一** | 缺少 `--verbose/--debug` 参数，排查问题不便 |
适合人群
- DevOps/平台工程师：CI/CD 流水线集成部署通知
- 运维团队：系统告警、监控事件推送至值班频道
- Google Workspace 用户：已启用 Google Chat API 的企业环境
- 自动化脚本开发者：需要将通知能力集成到 Python/Bash 工作流
常规风险
1. 凭据泄露风险：Webhook URL 和 OAuth Token 文件需严格保管，避免提交到代码仓库
2. 权限扩散：OAuth 授权范围较宽（chat.messages + chat.spaces），最小权限原则下建议定期审查
3. 消息伪造：Webhook URL 被截获后可能被滥用发送虚假通知，建议配合线程 key 或签名验证
4. 企业策略限制：部分 Google Workspace 管理员可能禁用第三方应用或 webhook 功能
5. API 配额：Google Chat API 存在调用频率限制，高频场景需考虑批量或降级策略
建议在生产环境部署前：① 人工审查代码 ② 添加 Token 文件权限控制 ③ 配置日志脱敏 ④ 建立凭据轮换机制。