纯 html 页面无法直接触发 slack 通知，因浏览器 cors 策略阻止跨域 post 请求，且硬编码 webhook url 会导致密钥泄露；安全方案需借助 github actions 或轻量后端代理转发。
纯 HTML 页面（index.html）本身无法直接触发 Slack 通知，因为浏览器环境禁止跨域 POST 到 https://hooks.slack.com/services/...，且没有服务端逻辑处理认证或状态判断。强行写 fetch() 会遇到 CORS 错误，或者暴露 SLACK_WEBHOOK_URL 导致密钥泄露。
为什么不能在 index.html 里直接用 fetch() 推送 Slack
Slack Incoming Webhook 要求 Content-Type: application/json 并接受 POST 请求，但浏览器对这类跨域请求有严格限制：
- Slack 的 webhook endpoint 不返回
Access-Control-Allow-Origin: *，所以前端直接fetch()必然失败，控制台报错Blocked by CORS policy - 把
SLACK_WEBHOOK_URL写死在 HTML 或 JS 里等于公开密钥，任何人查看源码就能盗用、滥发消息，甚至被用于钓鱼或刷屏 -
index.html是静态文件，没有运行时上下文（如 GitHub Actions 的${{ secrets.XXX }}或 Node.js 的process.env），无法安全注入凭证
可行替代方案：用 GitHub Pages + GitHub Actions 补足缺失环节
如果你的 index.html 托管在 GitHub Pages，真正的自动化必须后移到 GitHub Actions 工作流中，HTML 只负责“触发条件”（比如表单提交、按钮点击），由 Actions 拦截并转发。
- 用户在页面上点击「提交反馈」按钮 → 触发一个
POST到你自己的轻量接口（如 Cloudflare Workers、Vercel Edge Function、或任意能收 POST 的后端） - 该接口校验请求来源（如检查
Referer或加简单 token），再用服务端发起带密钥的 Slack 请求 - 更省事的做法：把用户行为映射成 GitHub Issue 或 Pull Request，用
on: issues或on: pull_request触发 Actions，再调用act10ns/slack@v2 - 不要试图用
location.href = 'https://hooks.slack.com/...'绕过 —— 这只会跳转失败，且 URL 中的密钥明文暴露
如果坚持只用前端：唯一安全做法是重定向到 Slack App 的交互式流程
Slack 官方支持通过 slack:// 协议或 https://slack.com/oauth/v2/authorize 引导用户授权，但这不是“自动推送”，而是“用户确认后发送”：
- 点击按钮后跳转到 OAuth 授权页，用户同意后回调你的域名，你拿到
access_token（仍需后端接收并存储） - 后续发送消息需用
chat.postMessageAPI，且必须走服务端（因为要签 Authorization header） - 纯 HTML 无法完成 OAuth 回调接收和 token 存储，浏览器无持久安全存储机制
- 这种路径适合内部工具，但复杂度远超“集成通知”的原始需求，且首次使用需人工点授权
真正卡住的地方从来不是“怎么写 fetch”，而是“谁来保管密钥、谁来承担发送责任”。静态页面天然不持有秘密，也不该试图扮演服务端角色。绕过这个约束的设计，99% 会在上线后变成安全漏洞或不可靠的半成品。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
