上线 QA 不是浏览一遍，是把关键路径跑成证据
这篇教程先把问题分成必须暂停、上线前修、上线后可补和上线后观察，再把页面、支付、物流、邮件、数据、政策、客服、移动端和异常路径收进一张上线回归测试表。没有订单号、截图、事件记录、复查人和复测状态，就不要说 QA 完成。
上一课留下的是 物流承诺与异常处理矩阵：为一个具名市场和 SKU 记录代表性结账运费、处理/运输时效、首扫与 tracking、税费说法、异常边界和暂停动作。
这份矩阵让你知道该测什么，但它没有证明真实买家能完成付款和下单，也没有证明承运商表现、税费结果、支付结算或上线已经获批。同一条承诺仍要经过当前的购买、订单、邮件、数据和客服路径。
所以这里把它接成一张 上线回归证据板：选定路径、留下证据，再给出 Go、Soft launch、Hold 或 No-go 的下一步；一张记录或一张被选中的卡片都不是上线批准。
先回答独立站上线前检查
Shopify 上线前要检查什么？订单、结账与数据验收清单
准备公开投流前，先核对独立站上线前检查清单、Shopify 测试订单怎么做、结账测试、移动端 QA，以及 Shopify 有订单但 GA4 没有 purchase 时的处理。本文把这些问题落到订单号、支付、邮件、移动端路径、事件参数和 Go、Hold、No-go 的放行证据上。
读完先能回答这三件事
- Shopify 上线前必须检查什么，哪些问题会直接暂停上线？
- Shopify 测试订单和结账测试怎么做，订单、退款和邮件要留下什么证据？
- Shopify 有订单但 GA4 没有 purchase 时，应该修复、延期还是暂停？
看过首页，不等于完成上线检查
真正上线后出问题，往往不在首页好不好看，而在手机端按钮、结账失败、运费突变、邮件没发、GA4 没 purchase、政策入口找不到、客服没人接。上线 QA 只认测试证据，不认感觉差不多。
用户路径
首页、集合页、产品页、购物车、结账、政策页和联系入口能从手机端跑通。
手机/桌面截图或录屏，记录设备、市场、浏览器和测试时间。
CTA 错链、移动端按钮被遮挡、政策入口找不到，就先不要公开投流。
先点这些路径，选择你现在最担心的一条。点完后，结果区会显示这条路径必须通过什么、要留下什么证据、失败后必须暂停什么；这个选择会自动进入最后的上线 QA 验收记录。
用 20oz 保温杯上线，别让第一批广告流量替你 QA
假设你准备上线一款 20oz 保温杯，广告承诺 2-5 天送达、满 49 美元免邮，首批流量来自 Meta 和 Google。上线 QA 要把承诺入口、订单路径和数据路径连起来看：买家看到的承诺、Shopify 后台的订单、GA4/Pixel/CAPI 的 purchase 事件，必须能互相对上。
承诺入口
订单路径
数据路径
工具报告是入口，不是结论
上线体检工具可以先发现公开页面、政策页、联系入口、移动端性能和基础追踪信号的明显缺口。但它不能替你完成真实购买测试。工具先扫，人工再跑订单、退款、数据和异常路径。
打开工具后，不要只看一个总分。选择报告里最接近的问题类型，结果区会告诉你带回哪些字段、人工还要补什么证据，以及最终写回上线 QA 验收记录的句子。
政策页 / 信任入口缺口
报告提示隐私政策、退款政策、配送政策、联系入口或页脚链接缺失、404、不可访问。
把失败 URL、页面类型、HTTP 状态、截图时间和复查人带回 QA 表。
人工再用手机打开这些页面，确认买家从产品页、页脚和结账页都能找到同一套承诺。
写回上线 QA 验收记录：政策缺口是否阻塞上线、修复链接、复测时间和是否允许 soft launch。
选完以后，先看它要求的证据和 Stop 条件。被选中的路径不是放行结论，只有把同一条市场/SKU 承诺跑进订单、邮件、数据或异常记录，才知道下一步是补证据、Hold 还是继续测试。
工具报告不是一个总分，七个放行门要分别判断
上线前最容易犯的错，是看到体检工具大体通过，就把支付、手机、追踪、政策、SEO、速度和客服入口混成一个“差不多”。这里要拆开：每个放行门都有工具信号、人工证据、Go 条件、Hold 条件和写回上线 QA 验收记录的位置。请选择当前最不稳的一项，结果区会给出放行判断。
工具报告只告诉你先查哪里。它不能把一个总分变成付款、订单、移动端、事件或客服路径的通过证明。最终上线判断仍要看订单号、移动端录屏、事件截图、邮件样本和人工复测。
支付放行门
工具只能提示支付入口、HTTPS、关键链接和结账路径风险，不能证明真实付款已经成功。
用主市场真实手机跑测试订单，保存订单号、支付状态、失败支付截图、退款或取消记录。
测试订单、支付成功、订单邮件、订单状态页和退款/取消路径都有证据。
支付按钮被遮挡、卡在跳转页、税费/运费突变、订单成功但后台没有记录。
写清支付网关、测试订单号、失败点、复测时间，以及上线当天谁盯支付失败。
上线前最后要把四条口径放在一起判断
工具报告、测试订单、移动端和事件截图都只是证据来源。真正的上线判断，要把公开页面、结账订单、追踪事件、运营客服四条口径放在同一张放行判断表里。请点击当前最不稳的一条口径，结果区会告诉你 Go 条件、Hold 条件、要留什么证据、谁确认，以及上线首小时盯什么。
公开页面口径
真实用户从广告、自然入口或首页进入后，能不能看到同一套商品承诺、政策入口和联系路径？
首页、主集合页、主商品页、页脚政策、联系入口和移动端首屏都能打开，且承诺不互相打架。
政策页 404、运费/退货承诺冲突、主产品页仍是占位图、移动端 CTA 被遮挡。
正式域名、主市场手机录屏、政策 URL、主商品页首屏截图和修复后复测时间。
页面/内容复查人确认承诺；运营复查人确认公开入口。
首小时只看公开入口、404、移动端首屏和客服入口，不临时重做主题。
不要只勾清单，要判断哪些错会直接影响下单
上线前最后一遍人工检查要把每个问题分成三类：今天能修并复测、需要延期复测、必须暂停上线。请点击当前最像你店铺的阻塞项，结果区会把用户风险、症状、三种处理方式和要留下的证据整理出来。
先选一个最危险的问题。目标是分清：哪些可以当天修，哪些要延期复测，哪些会直接影响收钱、下单、承诺或投诉，必须暂停。
结账和付款
买家点到最后付不了款、卡被拒、PayPal 回不来、折扣或税费变了，会直接丢单。
只在桌面跑过一单，手机端 Apple Pay、Shop Pay、PayPal、折扣码、税费和退款入口没有跑。
能当天修：支付按钮不显示、折扣码错误、地址提示不清、备用支付没打开。修完立刻用手机跑一笔小额订单。
要延期复测：支付服务审核、payout hold、税费/币种配置变更、checkout app 或扩展影响下单路径。
必须暂停上线：主支付不能成功收款，真实手机无法完成 checkout，退款/取消路径没人确认。
手机录屏、测试订单号、payment status、退款/取消记录、折扣和税费截图。
写回支付放行门、Payment Test Order Runbook 和上线 QA 验收记录。
至少跑一笔测试订单，并把前后链路都留下来
Shopify 的 test order 文档把 checkout、订单处理、库存、配送、邮件通知和税费设置都放在测试订单的验证范围内。用这笔测试订单证明这条链能从入口跑到订单状态和退款记录。
逐项点击你已经真的跑过的路径。不要为了让进度好看而全选：勾选数量会进入上线 QA 验收记录，后面复盘时会直接暴露哪些路径只是口头通过。
问题必须能收口：证据、复查人、复测缺一不可
QA 要把问题变成上线决定：哪些能上线，哪些必须停
同样是一个问题，影响支付和影响一行辅助文案，处理优先级完全不同。上线前先把问题分成 Blocker、Must-fix、Can-ship 和 Watchlist，避免团队被一堆待处理拖住。
点击最接近当前问题的分级。选完以后，把结果区的影响、规则、复查人和复测方式写进 QA 表；最终上线 QA 验收记录会记录你选择的分级。
Blocker：不能上线
支付失败、订单不进后台、移动端无法结账、核心政策找不到、正式域名不可访问。
只要影响下单、收款、履约承诺或售后入口，就不能带着上线。
复查人必须是能改设置或能协调修复的人，不是待观察。
修复后重新跑同一路径，补截图、订单号或事件记录。
遇到上线前异常时，先判断它会不会让真实用户替你测试
同一个 QA 问题，不能只写待处理。你要先判断它影响的是付款、订单、履约承诺、数据判断，还是只影响上线后可以修的小体验。下面四个场景用来训练上线前的阻塞判断。
点击最像你当前站点的问题。点击后看结果区的诱人错误动作、正确上线判断和第一证据，再决定这件事是 No-go、Hold、Must-fix 还是可以上线后观察。
桌面端测试订单成功，但手机端结账页弹窗或客服浮窗遮住支付按钮。
先上线，告诉用户可以关闭弹窗，或者只把桌面截图放进 QA 表。
No-go。移动端无法稳定付款就是上线阻塞项，先关掉遮挡组件或调整触发规则，再重跑手机端测试订单。
手机端录屏、设备/浏览器、结账页截图、测试订单是否完成、遮挡组件名称。
不能公开投流，不能只用桌面端证据替代手机端验收。
写回 QA 表的移动端路径、问题分级、复查人、复测截图和上线决策。
QA 结果必须落到 Go、Soft launch、Hold 或 No-go
上线前最危险的状态，是问题已经出现却没人做决定。把证据和问题分级翻译成四种决策：能公开投流、只能小流量观察、先修再上、完全不能上。这样第一批流量才不是盲试。
Go：可以公开投流
测试订单、移动端结账、邮件通知、退款路径、GA4 purchase、政策入口和客服入口都有证据。
可以开启首批公开流量，但先用小预算和明确观察窗口，不要一开始放大。
不要同时重做主题、支付、运费、像素或关键 app，否则 QA 证据会失效。
24 小时内看订单、支付失败、客服咨询、邮件送达和 purchase 事件；72 小时内复盘异常。
Soft launch：小流量观察
关键购买链路通过，但仍有 Watchlist，例如某市场运费转化、邮件进箱、客服咨询量需要真实流量判断。
只开放核心市场、少量 SKU 和小预算，先验证真实订单和客服压力。
不要开全市场、全广告组或大促承诺；不要把 Watchlist 当作已解决。
每天固定看 checkout drop、支付失败、物流咨询、退款原因和数据事件完整度。
Hold：先修再上
存在 Must-fix：不一定阻断付款，但会明显增加退款、咨询、投诉或数据误判。
可以继续限定范围复测、修正文案、补政策入口、重跑移动端和订单路径。
不要公开投流，也不要用未验收数据判断广告是否能放量。
修完当天必须复测同一路径，并把新截图、订单号或事件记录贴回 QA 表。
No-go：不能上线
存在 Blocker：支付失败、订单不进后台、移动端无法下单、正式域名不可用或客服/政策入口缺失。
只能修阻塞项、回滚高风险变更、重新跑关键路径回归。
不能上线，不能投流，不能让真实用户替你发现阻塞问题。
阻塞项必须由处理人关闭，并由第二个人按同一路径复测。
上线前最后 2 小时，不是继续改，是让每个人知道自己点什么、谁确认
很多新店不是死在没有检查，而是死在上线当天还在临时改主题、改 app、改运费、改追踪。这个作战室检查表把最后 2 小时拆成 5 个窗口：谁点什么、谁确认、留什么证据、哪些动作暂停。点击一个时间点，结果区会显示它应该怎么执行，并写入上线 QA 验收记录。
按时间从上到下跑。这里的重点不是多做几个检查项，而是让每个检查项都有点击人、确认人和证据；没有证据，就不要开第一批真实流量。
打开上线作战室，暂停高风险改动
上线复查人关闭主题、app、支付、运费、像素的临时改动入口，只保留阻塞修复通道。
第二个人确认正式域名、密码页、主商品、政策入口和客服入口都能打开。
留首页、产品页、政策页、客服入口、当前主题版本和 app 列表截图。
除非是 Blocker 修复，否则不改主题结构、不新增 app、不重接支付和追踪。
把两小时作战室的点击，落到设备、市场、收尾和观察记录
先按 Go、Soft launch、Hold 或 No-go 作出放行判断，同时记录判断背后常被漏掉的范围：到底在哪台设备、哪个浏览器、哪个市场和代表地址测过；测试订单或测试状态怎样收尾；首 24 和 72 小时准备看什么。这些记录不能代替发布许可。
主市场手机结账
记录真实手机型号、系统、浏览器和可用支付方式；不要用桌面开发者工具替代所有手机读回。
只针对当前准备开放的主市场和代表地址。别把一个地址的结果写成所有国家、地区或邮编都能结账。
从入口页到商品、购物车、结账、支付、thank you、订单状态、邮件和 Shopify 订单，记录同一路径证据。
支付、主 SKU、地址、运费、税费或确认页任一关键步骤无法完成时，暂停该路径的公开流量，修复后重跑同一设备和地址。
首 24 小时看失败支付、重复订单、订单邮件和支持入口；72 小时再看异常是否重复。
阻断上线
官方页面用于复核当前平台能力和边界，不替代真实后台、支付、市场、主题、应用或设备读回。官方页面复核日期：2026-07-26。
Shopify 测试订单
范围：用于确认测试订单可核对 checkout、订单处理、库存、配送、邮件通知和税费等设置，并复查测试方式是否影响真实用户下单。
怎么用：这里把测试订单放进同一条设备、市场、订单和收尾记录，不把一次模拟当成发布结论。
Shopify test-order documentationShopify 取消、归档与删除订单
范围：用于在真实后台核对订单取消、退款、库存、通知、归档或删除可用性和后续影响。可用动作取决于订单状态和付款方式。
怎么用：把测试订单收尾写成需后台读回的动作，而不是要求对真实订单执行统一处理。
Shopify order-cancellation documentationShopify Web Performance 报告
范围：用于理解 Shopify 管理后台的性能报告可按桌面和移动体验查看 Core Web Vitals，且报告数据可能有延迟。
怎么用：把性能报告与真实设备路径分开记录，不把历史报告、单个分数或模拟结果写成即时用户体验保证。
Shopify web-performance documentationShopify 主题无障碍实践
范围：用于提醒主题无障碍实践应结合实际键盘、焦点、内容和辅助技术复查，并不代表一次检查即可证明完全无障碍。
怎么用：这里只把键盘和关键路径复查纳入上线证据，不作无障碍合规结论。
Shopify theme accessibility documentation选一个做法，检查它是否先记录真实测试范围和证据，再回到已有放行表作出 Go、Soft launch、Hold 或 No-go 判断。
只记录本次检查所需的非敏感信息。不要输入客户姓名、完整地址、订单号、支付资料、账号凭据、完整录屏链接或内部账户截图。
此记录只保存在当前浏览器或你的本地下载文件中，不会写入 Shopify。
先把 CAPI 和 attribution 说清楚，再验收数据路径
新手最容易在数据 QA 里卡住：不是因为不会看报表，而是不知道这个词到底在哪出现、谁会读取、错了会影响什么。下面两个词先讲清楚，再去看 purchase 事件。
CAPI
CAPI 是 Conversions API，意思是让服务器把订单、加购、结账等转化信号发给广告平台，而不只依赖浏览器里的 Pixel。
你会在哪里看到：你通常会在 Meta Events Manager、Shopify app、服务器端追踪或系统集成设置里看到它。
错了会怎样：如果 CAPI 和 Pixel 重复记单或漏记单，广告系统会把错误订单质量当成优化信号。
attribution
attribution 是归因，意思是平台把一次订单的功劳分给哪个广告、关键词、内容或渠道。
你会在哪里看到：你会在 GA4、Google Ads、Meta Ads、Shopify 报表和 UTM 报告里看到不同归因口径。
错了会怎样：如果 purchase、UTM 或订单金额不完整，你会把预算加给看起来赢、实际上没有贡献利润的流量。
放广告前，先证明 GA4 和广告事件不是空的
GA4 ecommerce 事件不会因为页面好看就自动正确。至少要能在 DebugView 或事件测试里看到 view_item、add_to_cart、begin_checkout、purchase，并确认 transaction_id、value、currency、items 这类 purchase 参数不缺。
view_item用户看过商品。
item_id / item_name 不缺失。
add_to_cart用户把商品加入购物车。
value、currency、items 能和购物车对上。
begin_checkout用户进入结账流程。
商品、金额、优惠码和来源线索还在。
purchase订单完成。
transaction_id、value、currency、items 必须完整。
手机端不是缩小版桌面端，它有自己的失败点
移动端真正影响转化的，经常是输入、键盘、弹窗、地址字段、sticky button、支付跳转和返回路径。桌面端正常，不代表手机端订单路径 ready。
点击你已经在真机或移动视口里验过的项目。移动端勾选数量会写入上线 QA 验收记录；如果没有录屏或截图，就不要勾。
只测成功路径，会漏掉真实用户最容易卡住的地方
选择你最担心的异常路径。结果区会告诉你该怎么测试、过关标准是什么；这个选择会进入最终上线 QA 验收记录，提醒你上线前别只测成功订单。
用户看到清楚提示，能返回重试或换支付方式。
没有死路，客服知道如何查失败订单。
如果没有证据，就不要把已检查写进上线表
你已经看过首页和产品页，但还没有测试订单号、移动端结账截图和 GA4 purchase 记录。现在最应该怎么判断？
上线当天最需要稳定路径，不是继续装修
正式上线或首次投流当天，不要同时做一堆大改。每一次主题、支付、税费、运费、app、像素变更，都可能让前面 QA 证据失效。
上线当天不重做首页、产品页、结账前路径和移动端结构。
除非是阻塞修复，否则不要同时改多个会影响真实订单的设置。
未验证转化前，不要继续增加月费、脚本和页面速度负担。
数据验证完成后暂停事件结构改动，避免第一批数据不可用。
当前流程引用官方文档，是为了界定 QA 范围
官方资料核验日期：2026-06-29。Shopify checkout、thank you、order status、customer accounts、Customer events、GA4 和广告事件入口会变化，以上线前后台当前显示为准。
QA 表会告诉你下一步该补哪里
把这篇教程变成上线 QA 验收记录
最后不要只写我都看过了。这里会自动带入你刚才点击过的回归路径、问题分级、阻塞场景、移动端数量、异常路径和下一步路线；你再补上当前压力、第一证据、本周动作、暂停动作、复盘窗口和下一步路线。
当前回归路径: 用户路径 - CTA 错链、移动端按钮被遮挡、政策入口找不到，就先不要公开投流。 已勾选主路径: 2/6 问题分级: Blocker：不能上线 - 只要影响下单、收款、履约承诺或售后入口，就不能带着上线。 上线阻塞场景: 手机端支付按钮被遮挡 - No-go。移动端无法稳定付款就是上线阻塞项，先关掉遮挡组件或调整触发规则，再重跑手机端测试订单。 2 小时上线作战室: T-120 分钟 打开上线作战室，暂停高风险改动 - 除非是 Blocker 修复，否则不改主题结构、不新增 app、不重接支付和追踪。 上线体检工具写回: 政策页 / 信任入口缺口 - 写回上线 QA 验收记录：政策缺口是否阻塞上线、修复链接、复测时间和是否允许 soft launch。 体检工具放行门: 支付放行门 - 写清支付网关、测试订单号、失败点、复测时间，以及上线当天谁盯支付失败。 上线放行判断表: 公开页面口径 - 首小时只看公开入口、404、移动端首屏和客服入口，不临时重做主题。 最后人工检查: 结账和付款 - 付款路径影响收钱，不能靠“看起来能点”放行。 上线证据矩阵: 主市场手机结账 - 阻断上线 上线证据关卡: 0/5 上线证据判断: ___ 测试目标与当前开放范围: ___ 设备、浏览器与市场读回: ___ 证据位置与问题分级: ___ 测试订单与测试状态收尾: ___ 当前判断与暂停条件: ___ 首 24 / 72 小时观察: ___ 移动端验收: 1/4 异常路径: 支付失败 - 没有死路，客服知道如何查失败订单。 快速自测反馈: 尚未选择快速自测答案 下一步路线: 异常路径还没人处理 - 先把退款、丢件、邮件失败、支付失败和用户咨询写成客服处理路径。 当前压力: ___ 第一证据: ___ 本周动作: ___ 暂停动作: ___ 复盘窗口: ___ 上线放行判断表: ___ 最后人工检查结论: ___ 下一步路线: ___
Basics 关联阅读
先把上线验收接回物流和客服
上线 QA 要把商品、结账、邮件、物流和客服异常放在同一条测试路径上。下面的链接帮助继续核对承诺与处理人，但不证明上线已经完成或订单一定成功。