用 Tampermonkey 自动化工作流，同时避开脆弱脚本陷阱
Tampermonkey 工作流自动化是指通过 userscript 从网页界面识别信息、应用明确规则，并辅助或执行一项边界清晰的浏览器任务。当浏览器本身就是工作场所、修改底层系统并不经济，而且人员仍应参与决策时，它可能是最快且负责任的方案。
关键在于边界清晰。Userscript 是界面侧自动化层，不是新的事实来源。它可以突出异常、减少重复导航，并在页面刷新后恢复受控流程，但不应悄悄取代授权、服务端验证或可审计的业务逻辑。
Tampermonkey 何时是合适的自动化层？
以下五项条件全部成立时，Tampermonkey 通常很合适。如果有两项或更多不成立，应在编写 userscript 前先评估 API、RPA 平台或后端服务。
| 条件 | 适合的信号 | 风险信号 |
|---|---|---|
| 范围 | 一个角色、少数已知页面、一个清晰结果 | 多个部门、系统和大量异常路径 |
| 风险 | 可撤销的界面辅助或可确认操作 | 不可逆的财务、法律或库存决策 |
| 吞吐 | 人员在线时按人工节奏执行 | 无人值守、高吞吐或时间关键处理 |
| 数据 | 登录用户本来就能看到的信息 | 密钥、大规模导出或跨租户数据 |
| 责任 | 指定维护者能测试界面变更 | 没有负责人、测试账号或回滚路径 |
Userscript 头部也是安全模型的一部分。Tampermonkey 的 @match 与 @exclude 限制脚本运行位置，@grant 则声明特权 API。应把这些字段当作权限，而不是样板文字。具体行为以Tampermonkey 官方文档为准。
可维护的 userscript 应分为四层
- 上下文识别。执行任何操作前，先验证 URL、页面身份和预期界面标记。
- 语义提取。把标签、可见值、标题和稳定属性转换为小型内部模型。
- 规则与决策。运行不操作 DOM、可独立测试的纯规则。
- 效果与状态。呈现提示或执行受保护操作，只保存安全恢复所需的最少信息。
这种分层会改变维护成本。前端更新移动某列时，只需修复提取器，而不必同时重写业务规则和界面效果。规则变化时，也能用普通对象测试，无需打开目标应用。
语义比位置更稳定
“第二个表格的第四个单元格”描述的是布局偶然性；“查找标题规范化后等于预期业务标签的列”描述的则是含义。后者更能承受列顺序变化、可选字段和界面改版。
当关键信号分散在页面文本中时，TreeWalker 可以按过滤条件遍历文档子树。内容是信号、组件没有稳定钩子时可采用它。先收集匹配项，再修改 DOM，避免脚本新插入的标记在同一轮处理中变成新的输入。
应假设 DOM 在加载后仍会变化
现代后台界面会异步渲染面板、行和汇总值。只在 DOMContentLoaded 时扫描一次，容易漏掉合法状态。MutationObserver 能让代码响应 DOM 树变化。回调应防抖，观察范围应缩小到必要子树，并尽可能只重扫受影响区域。
轮询可以作为防御性后备方案，但必须有间隔、上限和停止条件。Observer 再加上无限制的全页面轮询，会制造性能缺陷，而不是提升韧性。
避免重复和不安全操作的五种模式
| 模式 | 实现规则 | 避免的问题 |
|---|---|---|
| 幂等 | 同一轮处理执行两次，界面结果仍相同 | 重复提示和重复操作 |
| 处理标记 | 只有在目标效果确实存在后才标记 | 渲染不完整导致任务被跳过 |
| 稳定身份 | 保存业务稳定的行标识，不保存视觉索引 | 排序或刷新后操作错误行 |
| 操作前检查点 | 触发导航前先保存下一可恢复状态 | 页面刷新时丢失进度 |
| 安全失败 | 标签或数量不明确时停止 | 界面变化后继续猜测 |
Tampermonkey 通过 GM_setValue、GM_getValue 等 API 提供持久化键值存储。它让跨页面流程成为可能，也会带来过期状态风险。只保存版本、工作流标识、上个检查点和过期时间，并提供可见的重置入口。不要因为 API 使用方便，就把凭证或整份业务数据存进去。
重复的浏览器流程持续消耗注意力，但重写整个平台又为时过早？
规划安全的自动化试点安全与治理应进入第一版
- 最小权限：采用最窄 URL 规则和最少的特权 API。
- 不增加隐含权限：脚本不能让用户执行目标应用本来会拒绝的操作。
- 人员确认：破坏性、对外或财务相关操作前保留审核步骤。
- 数据最小化：只处理屏幕上必需的信息，并尽量少做持久化。
- 变更控制：为脚本做版本管理，指定负责人，测试代表性布局，并保持一键回滚。
- 失败可见：匹配不完整时显示明确停止状态，而不是静默继续。
Iframe 访问存在明确的平台边界。浏览器的同源策略会限制一个源的脚本与另一个源的文档交互。不要设计依赖读取跨源 iframe 的流程，再把预期出现的安全错误误判为选择器问题。
Userscript 何时应升级为后端集成？
浏览器自动化证明规则有效并降低不确定性，就已经成功。当流程需要在浏览器关闭后运行、处理大量任务、保证操作恰好一次、执行权限、生成长期审计记录或连接多个系统时，就应升级。
应在试点前定义这条界线。可用指标包括每日执行量、需要支持的页面变体数量、每次界面发布后的维护工时，以及漏做或重复操作的成本。这样，升级会成为工程取舍，而不是为一个已经超出职责的脚本进行情绪化辩护。
如果你正在浏览器层与更深度的系统建设之间选择，可以参考我们的定制软件与现成软件决策指南。Wavect 的定制软件开发团队也可以评估工作流、风险边界和成本最低的可维护架构。
实用评审清单
- 能否用一句话描述流程并指出负责人？
- 脚本是否只在明确列出的页面运行？
- 识别、规则、效果和持久化状态是否分离？
- 每轮 DOM 处理能否执行两次，而不重复输出或操作？
- 必要语义标记消失时，脚本是否会停止？
- 用户能否查看、重置并安全放弃保存的流程？
- 每个支持的界面变体是否都有测试样例？
- 何时迁移到 API 或后端服务，是否已经写明？
Tampermonkey 工作流自动化常见问题
Tampermonkey 适合企业流程自动化吗？
怎样让 Tampermonkey 脚本适应界面变化？
Userscript 能在页面刷新后继续吗？
Tampermonkey 脚本应该自动点击按钮吗？
何时应以 API 取代浏览器自动化？
最终思考
优秀的 userscript 会刻意保持小巧。它从浏览器界面读取含义，应用明确规则，让人员的下一步操作更安全或更快。页面发生变化时，工程质量才真正显现：它不会猜测、重复或静默继续。第一版就应包含安全边界、责任人和退出条件。这样，浏览器端自动化才是有效的产品决策，而不是永久补丁。