VS Code 官方不推荐直接集成 Slack，因旧扩展依赖过时 API、权限升级失败、Webview 不兼容且无错误日志；可靠方案是终端脚本 + Slack Webhook，通过捕获命令输出并清洗后推送。
vscode-slack 扩展已停止维护，官方不推荐直接集成 Slack 到 VS Code 编辑器主界面。真正可行、稳定且被广泛采用的方式，是通过终端输出捕获 + Webhook 脚本触发通知。
为什么不能直接装个“VS Code Slack 插件”就完事？
市面上曾有 vscode-slack、slack-notifier 等扩展，但它们存在几个硬伤：
- 依赖过时的 Slack API v1 或 deprecated 的 Incoming Webhook 格式，2024 年起大量报
invalid_payload或missing_text - 无法处理 OAuth 2.0 scope 权限升级（如
chat:write必须显式授权），导致安装后静默失败 - 不兼容 VS Code 1.85+ 的 Webview 安全策略，加载时触发
Refused to display 'https://slack.com/' in a frame - 没有错误日志输出，失败时仅在状态栏闪一下图标，根本不知道哪步断了
用终端脚本 + Slack Webhook 实现可靠通知
这是目前最轻量、可调试、权限可控的方案。核心逻辑：让 VS Code 终端执行命令后，自动把 stdout/stderr 推送到 Slack。
- 先在 Slack 后台创建一个 Incoming Webhook（路径：
Slack App → Features → Incoming Webhooks → Add New Webhook），复制生成的 URL - 新建一个本地脚本
notify-slack.sh，内容如下：
#!/bin/bash
WEBHOOK_URL="https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXX"
PAYLOAD=$(jq -n --arg msg "$1" '{text: $msg}')
curl -X POST "$WEBHOOK_URL" \
-H "Content-Type: application/json" \
-d "$PAYLOAD"
- 在 VS Code 终端中这样调用它：
npm test && ./notify-slack.sh "✅ 测试全部通过" || ./notify-slack.sh "❌ 测试失败，请检查"
- 如果想捕获上一条命令的完整输出（比如构建日志），改用：
OUTPUT=$(npm run build 2>&1); echo "$OUTPUT" | head -n 50 | ./notify-slack.sh "$(echo "$OUTPUT" | tail -n 10)"
如何避免敏感信息泄露到 Slack？
终端输出常含路径、用户名、token 片段。直接转发极不安全。必须做清洗：
- 永远不要用
$(cat ./build.log)这类裸读取，优先用head/tail控制行数 - 用
sed过滤敏感字段，例如：
OUTPUT=$(npm test 2>&1 | sed 's/\/home\/[^ ]*//g; s/token=[^& ]*//g')
- Webhook URL 必须存为环境变量或
.env文件，绝不可硬编码进脚本或 Git 提交 - Slack 频道需设为私密，禁用外部共享链接，避免 webhook URL 意外暴露
Live Share 场景下怎么让协作者也收到通知？
默认情况下，脚本只在发起者本地终端运行，协作者看不到通知。要同步，得靠共享终端本身：
- 启动
Live Share会话后，所有参与者共用同一个终端实例 - 把通知脚本放在项目根目录（如
./scripts/notify.sh），并确保git add进仓库 - 在
package.json中统一定义 script：
"scripts": {
"test:notify": "npm test && ./scripts/notify.sh '✅ Test passed' || ./scripts/notify.sh '❌ Test failed'"
}
- 协作者只需运行
yarn test:notify，就能触发同一套通知逻辑
关键点在于：通知不是“VS Code 自动推”，而是“谁执行了命令，谁负责推”。这反而更可控，也避开了权限模型和沙盒限制。真正的难点从来不在“怎么发”，而在于“什么时候发、发什么、发给谁、是否脱敏”。
