最安全的中止按钮需同时满足：type="button"防误提交、confirm二次确认、仅status==="running"时显示、POST/DELETE请求带CSRF token、202/200状态码区分、红色+图标+aria-label保障可访问性。
按钮必须带确认且禁用默认表单提交
直接写 <button type="button">中止</button> 是最安全的起点。如果按钮在 <form> 里却没声明 type，点击会触发 submit，可能意外刷新页面或提交空数据。紧急操作不能容忍这种干扰。
真实场景里，用户手滑点错的概率远高于预期，所以必须加二次确认：
- 用
onclick="if(!confirm('确定中止当前任务？此操作不可撤销'))return false;"拦截 —— 简单有效，不依赖额外 JS 框架 - 避免用
alert()，它无法阻止后续逻辑执行，且体验生硬 - 确认弹窗文案要明确后果，比如强调「正在运行的任务将立即终止，进度无法恢复」
按钮状态需实时同步后端任务状态
中止按钮不是“点了就完事”，它得反映真实系统状态。常见错误是前端静态渲染一个常驻 中止 按钮，但任务早已结束或根本不存在 —— 这会让用户误以为还能操作，甚至触发 404 或 409 错误。
正确做法是服务端返回任务当前状态（如 status: "running"），前端据此决定是否渲染按钮及是否启用：
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 仅当
status === "running"时才显示按钮，其他状态（"completed"、"failed"、"canceled"）完全隐藏 - 按钮初始为
disabled，点击后立即设为disabled并显式置灰，防止重复点击 - 中止请求返回成功后，应主动更新 UI：按钮变文字为「已中止」，或整体移除
中止请求必须用 POST 或 DELETE，不能 GET
HTTP 规范里 GET 请求必须是安全的、可缓存的、无副作用的。用 GET /api/tasks/123/stop 不仅违反语义，还容易被浏览器预加载、代理缓存，甚至被爬虫误触 —— 后果可能是生产环境任务批量中止。
标准做法是：
- 用
POST /api/tasks/{id}/cancel（更通用）或DELETE /api/tasks/{id}（若语义上等价于销毁任务实例） - 携带 CSRF token（尤其在传统后端渲染页面中），否则请求会被拦截
- 响应状态码要准确：
202 Accepted表示中止指令已接收（异步执行），200 OK表示已同步完成；避免全用200
按钮样式要传递紧迫感但不牺牲可访问性
红色按钮不是万能解。纯靠颜色区分会筛掉色觉障碍用户，且深色主题下可能完全看不清。真正关键的是组合信号：
- 背景色用高对比度红（如
#d32f2f），同时加粗文字 + 图标（如 ⚠️ 或 ?） - 必须设置
aria-label="紧急中止 ID 为 123 的任务"，让屏幕阅读器读出具体对象 - 悬停和焦点状态要有明显变化（如阴影加深、边框加粗），键盘用户 Tab 到按钮时不能丢失视觉反馈
- 禁用态要用
opacity: 0.5+cursor: not-allowed，而不是只改颜色 —— 否则用户会怀疑是不是自己没点到
复杂点不在怎么画按钮，而在于状态闭环：从接口返回值判断能否点、点了之后立刻锁住、成功后更新视图、失败后还原按钮并提示原因 —— 少一环，用户就会反复点，后台可能收到一堆重复中止请求。
