VKT Toolkit · 2026年10月23日 · 约 7 分钟

VKT Cart Lock 支持哪些商店？24 个预设与通用兜底

简短的回答是「大概率就是你要的店」，但这句话值得用一整页来讲。结账锁只有在识别出结账环节时才起作用，而识别是整个产品里最不性感的部分。这份指南列出全部预设，解释预设多了什么，也会明确说清楚哪些情况下这把锁帮不上忙。

24 个预设，加上其它所有地方

VKT Cart Lock 自带 24 个站点预设和一个通用兜底。预设就是下面列出的 24 家商店；兜底则让扩展在长尾商店上也能用。两者都不是承诺，下面会如实描述。

机制不因商店而变：第一次点击结账就会启动倒计时，订单不会提交，在计时结束前结账按钮、链接、表单提交和结账页面会一直被拦截。没有跳过或贪睡，计时器能扛过关闭标签页或重启浏览器。预设改变的只是结账环节被识别出来的可靠程度。

完整预设清单

一共 24 个。分类只是为了方便阅读，不代表行为不同——每个预设在各自的商店里做的是同一件事。

预设多了什么

在预设商店上，扩展知道结账通常在哪里：该盯哪些按钮和链接、该拦哪些表单提交、哪些页面结构意味着结账环节。这很重要，因为按钮上的字并不稳定。商店会测试不同的文案、做本地化，还会挪动主操作的位置。

在不在名单上的商店，扩展会退回到匹配结账文本——「checkout」「buy now」「place order」——以及常见选择器。实际上这能覆盖大多数标准购物车，包括许多跑着熟悉平台的小店。但对于只有图标的按钮、不常见的措辞，以及整条流程里从不出现「checkout」一词的自定义结账，它就没那么确定了。

两个实际后果。第一，不在名单上的商店不是死路；先试一试，再断定它不行。第二，如果你常在某家店买而计时器从不启动，别一直试——把该域名加入强制锁定，并反馈那个页面。

为什么排除支付页面

支付服务商的页面和内嵌框架——Stripe、PayPal、Adyen、checkout.com、Braintree——被明确排除在扩展的作用范围之外。它从不在输入卡号的支付服务商页面或内嵌框架中运行。

理由有三个，而且都是刻意的。支付环节是最不该出问题的地方：卡号表单被拦住是一次客服事故，而不是一段冷静期。等到支付页面加载出来，决定其实已经做完了——有用的干预要更早，在点击结账那一刻。此外，把扩展的作用范围从支付框架中拿开，也让它的权限和行为更容易推敲。

诚实的后果是：如果一家商店从商品页直接跳进快捷支付框架，中间没有正常的结账环节，这把锁就没有可拦的东西。强制锁定在有结账触发点的地方有用；没有触发点的地方，浏览器扩展就不是那笔购买该用的工具。

不支持的商店与误拦

两个不同的问题，两套不同的解法。

• 结账没有被拦住。把域名加入强制锁定列表，标记为始终锁定，不再依赖匹配。然后做一次测试下单，确认计时器会启动。如果网站仍然顺利通过，把网址和按钮文案发到支持邮箱；
• 有不该拦的东西被拦了。用误拦反馈。点一下就把该元素标记为误报，下次会被排除，同一个页面不会反复触发锁定。对于那些只是提到结账的页面——退货政策、帮助文章、卖家后台——这是最快的路径。

强制锁定和白名单方向相反，所以要有意识地使用：同一家店不该同时出现在两个列表里。对于多数消费又小又偶发的商店，小额豁免往往比把整个域名加进白名单更干净。

「支持」不意味着什么

把边界说清楚是值得的，因为在这一块夸大其词只会带来失望的用户：

• 仅限桌面。VKT Cart Lock 是 Chrome 和 Edge 扩展；它不在手机浏览器里运行，也不在购物 App 里运行；
• 不管线下。这把锁对线下的收银台没有任何意见；
• 不是每一种结账变体。大商店会做实验，预设没见过的布局在被反馈之前可能漏过去；
• 不管支付。如前所述，支付页面不在范围内，这是设计决定，不是遗漏。

在这些限制之下，现实的承诺不大，但有用：在你真正会用的商店上，这把锁通常能抓住结账环节；抓不住的时候，强制锁定加一次反馈，两分钟就能补上。如果你还没配置过，10 分钟设置指南会按顺序走一遍豁免和强制锁定的界面。

FAQ

更多指南见 VKT 博客；问题反馈：[email protected]。