Shopify 年龄验证（Age Gate）实施指南：分流、隐私与安全回退

年龄门槛不是一个贴在首页上的装饰性弹窗，而是一套决定“谁能看到什么、何时需要更强核验、验证失败后如何停住”的访问与运营设计。对 Shopify 店铺来说，最容易犯的错误，是把所有问题压缩成“找一个年龄验证应用”。事实上，Online Store 前台拦截、商品与市场范围、第三方核验、隐私数据、人工处理，以及 Shop 渠道资格，属于彼此相关但不能互相替代的层次。

这篇指南聚焦年龄门槛本身。年龄门槛不构成法律意见，也不能凭一段前台脚本就证明店铺满足任何特定地区的规则。适用产品、销售市场、合作伙伴要求和当地规则不同，发布前应由商家自行核对，并在需要时咨询自己的法律顾问。Shopify 并没有一个适用于所有店铺、商品和市场的通用原生 age-gate；店铺要根据风险和渠道选择分层方案。

先定义问题：门槛究竟要阻断什么

年龄门槛的第一步不是选技术，而是写清楚要保护的对象。可能需要限制的是整站访问，也可能只是某些商品、某个系列、某个市场，或者某类内容的继续浏览。范围不同，用户体验、数据采集和故障处置都会不同。

如果一个店铺只需要让访客确认“我已达到适用年龄”，这更接近提示和访问分流；如果店铺需要依赖出生日期、身份证件或第三方服务来做更强的年龄判断，则需要处理第三方传输、字段最小化、保留期限、失败状态和人工审查。不能因为两个流程都叫 age gate，就把它们当成同一种证明。

访问门槛与年龄证明不是一回事

前台弹窗可以在访客进入首页、商品页或特定内容前展示选择。访客点击确认后，浏览器可能记住这一选择，使同一设备在一段时间内不重复询问。这能改善体验，却不能自动把自我声明升级成强身份或年龄证明。它也不能说明操作人就是该设备的真实持有人。

第三方验证可能提供更强的核验流程，但强弱取决于服务如何核验、店铺为什么需要它、向谁提供结果、保存哪些字段以及如何处理错误。店铺不应把“收到一个通过值”理解为万能结论。应把结果限定为某个产品、市场和会话中的业务判断，并留下可解释的失败与人工处理路径。

不要把商家账户年龄要求混进来

商家开户或使用平台的资格，是平台与商家之间的关系；顾客能否浏览或购买受年龄限制商品，是店铺面向访客的业务流程。两者对象、证据和处理方式不同。写方案时不要把商家账户条款中的年龄要求当成顾客年龄验证规则，也不要用顾客在弹窗中点选的结果去推断商家账户资格。

这样区分还有一个实务价值：当店铺要更改受限商品范围时，团队可以只更新面向顾客的分流和核验，而不会误以为需要改动整个商家账户设置。反过来，平台政策发生变化时，也应单独复核商家资格、商品资格和渠道展示条件。

Shopify storefront 的责任分层

一个可靠的设计至少要画出四个边界：Online Store 前台、商品与市场规则、验证服务、人工处置。前台负责给出清楚的状态和阻断动作；商品与市场规则负责决定哪些内容需要门槛；验证服务只提供约定范围内的结果；人工流程负责处理服务不可用、误判和用户申诉。

Online Store 前台负责展示与阻断

Shopify 的主题可以借助 theme app extensions 增加动态元素。App blocks 和 app embed blocks 能让应用把前台元素接入主题，并由商家在主题编辑器中配置位置。对于年龄门槛，这通常适合放置进入提示、遮罩、按钮、说明文案和状态反馈。

但前台组件只是一个执行点，不是完整的年龄证明系统。若页面脚本没有加载、访客直接打开商品深链接、缓存返回了旧页面，或者用户关闭了脚本，受限内容不能因此自动变成可访问。高风险商品要有独立的范围判断和失败状态，不应只依赖浏览器里的一个布尔值。

商品、市场与渠道决定规则范围

同一家店可能同时拥有无年龄限制的普通商品和需要年龄门槛的商品；同一商品也可能面对不同市场。把全站一刀切，会给普通内容增加不必要的摩擦；把所有内容都当作普通页面，又会让受限商品缺少明确阻断。最初的产品清单应先按范围拆分，再决定每一层需要的提示或核验。

上线前的产品与市场分流

在配置应用以前，先做一张范围表，至少包含产品、内容、目标市场、销售渠道、所需门槛强度和负责人。年龄门槛不应该以“全站都有”作为默认答案。对于不确定的产品或市场，宁可先停留在人工复核状态，也不要让脚本替团队猜测。

用产品矩阵决定门槛强度

把商品按访问风险和运营后果分成几类，而不是只看商品名称。需要门槛的原因可能来自产品本身、内容呈现方式、市场条件或合作伙伴资格；资料卡没有为任何具体地区规定统一年龄数值，因此文章不应替商家填写一个看似确定的阈值。

用市场矩阵决定是否放行

店铺可能让不同地区看到不同商品、页面或渠道。不要用一个全局 cookie 推断所有市场都已经完成同一判断。应明确市场识别是否可靠、识别失败时如何处理，以及是否需要人工确认。任何市场规则都不应被写成“适用于所有国家”的保证。

这一步可以借助 Shopify 技术审查清单实战指南：用正确顺序优化你的 T&C 店铺 做页面、条款和功能的发布前核对，但年龄门槛的适用性仍要单独判断，不应把一般技术检查当成法律确认。

两条实施路线：自我声明与第三方验证

选择路线时，先问“需要什么判断结果”，再问“用哪个应用”。如果只需要一个清晰的访问提示，自我声明可能已经足够作为产品层面的分流；如果业务需要更强的年龄判断信号，则要评估第三方服务的字段、地域、可用性和人工处理。两条路线也可以按产品和市场并存，但必须让访客知道自己处于哪一种流程。

自我声明适合什么场景

自我声明的核心是让访客确认自己达到店铺为该范围设定的适用年龄，并在拒绝或不确定时不继续进入受限内容。它应当使用平实文案，说明访问限制的原因，提供隐私说明和联系路径。不要让按钮文案暗示“完成认证”或“已被身份核验”，因为这会夸大流程实际完成的事情。

自我声明还要考虑重复访问、共享设备、浏览器清理和访客打开深链接等情况。记住选择可以减少重复打扰，但不应被写成永久证明。需要更强判断的商品不应因为访客曾经通过普通页面提示，就自动跳过更强流程。

第三方验证适合什么场景

第三方验证的价值在于把必要的判断交给专门流程处理，而不是让主题代码自己读取身份证件或建立一套未经验证的规则。接入前要确认服务返回的到底是最小的年龄判断结果，还是包含出生日期、证件图像、精确位置、设备信息等更广泛的数据。店铺应尽量只接收完成业务判断所必需的结果。

第三方服务失败、超时、返回不确定结果或无法解释时，默认状态应为不放行。恢复路径可以是再次尝试、转人工、关闭受限商品曝光或暂时撤下受影响范围，但不应静默跳过验证。服务方的条款和隐私安排也不能代替商家对产品、市场和客户说明的核对。

混合路线要有清楚的升级条件

混合路线可以让低风险入口先采用自我声明，而在特定商品、市场或异常状态下升级到第三方流程。升级条件应写成可测试的规则，例如受限商品范围、市场无法确认、访客对结果提出异议、验证服务返回待审，而不是由页面脚本临时决定。

前台阻断的页面与状态设计

一个年龄门槛的质量，往往取决于失败状态是否清楚。页面不能只设计“通过”按钮；还要设计拒绝、不确定、服务不可用、会话过期、深链接和普通内容继续访问等状态。用户应知道发生了什么、下一步能做什么，以及为什么受限内容没有显示。

入口页要先说明再请求

入口页应说明受限范围、访问需要完成的步骤、数据用途的简短提示、拒绝后的可选路径和联系方法。若年龄门槛只针对某个商品或系列，尽量在进入该范围时出现，而不是阻挡所有无关页面。说明文字不要暗示平台已经替店铺作出法律判断。

按钮至少应区分“确认并继续”“我不满足或不确定”“返回普通内容”或“联系店铺”等动作。对于第三方流程，还应说明将跳转或传送到哪个服务，并在返回后显示明确结果。不要用模糊的“开始购物”掩盖核验步骤。

拒绝与不确定要保持受限

拒绝、空白、矛盾结果、市场不明、验证超时，都不应进入受限商品页。页面可以提供非受限内容、政策页、客服邮箱或人工表单，但不要把“联系客服”设计成点击即放行。人工处理需要有范围、记录和再次判断。

对有无年龄限制的内容共存的店铺，拒绝受限内容不等于把整站变成错误页。可以让用户继续浏览非受限信息，同时明确不能继续访问的部分。这种分流既减少不必要的挫败，也更容易由工作人员定位问题。

深链接和会话状态要按最坏情况测试

测试不能只从首页进入。应直接打开受限商品 URL、刷新页面、返回浏览器、清除站点数据、换设备、禁用脚本、重复点击按钮，并模拟服务超时。只要某一条路径在没有有效判断时展示了受限内容，就应把它列为阻断缺口。

需要梳理主题、应用区块和页面路径时，可以参考 Shopify 建站教程：从基础到上线独立站的全流程操作指南。这里的重点仍是年龄门槛：教程类内容只能帮助整理页面流程，不能替店铺决定某地规则。

最小数据与隐私边界

年龄门槛最容易扩张成“能收集什么就收集什么”。实际设计应从最小字段开始，并为每个字段写明用途、访问者、保留时间和删除方式。没有明确必要性时，不要默认采集出生日期、身份证件图像、精确位置、指纹或完整设备资料。

Customer Privacy API 的 consent 不是年龄证明

Customer Privacy API 用于判断分析、营销、偏好和数据出售等处理是否获得许可，并不是年龄证明接口。访客允许某类数据处理，不等于访客已经证明自己达到某个年龄；店铺也不能用 consent 状态替代年龄门槛结果。

同样，不能把年龄门槛的点击当成所有数据处理的同意。官方说明强调同意应来自访客交互，且不能直接读写 Shopify cookie。年龄流程和隐私同意流程要分别写清楚：一个回答“是否允许继续访问某范围”，另一个回答“是否允许某类数据处理”。

先问结果，再决定字段

如果页面只需要知道“已通过某一年龄判断”，就应优先接收通过、未通过、待审或服务不可用等状态，而不是要求店铺保存完整出生日期。若第三方服务必须处理更多资料，店铺也应确认是否可以只返回判断结果，并让原始资料留在必要的处理链路中。

让访客知道数据如何结束

说明应告诉访客哪些资料由谁处理、用于什么、保留多久、如何提出问题。若店铺只保存“已完成某门槛”的短期状态，就应避免文案让人以为店铺保存了证件。若需要人工审查，应说明人工会看到哪些必要信息以及怎样结束处理。

数据最小化也包括访问权限最小化。客服不一定需要看到完整核验资料，主题代码也不应把第三方返回对象全部写入浏览器或日志。审查记录可以保留决定、范围、时间和处理人，但不应为了方便而复制不必要的原始数据。

主题集成与配置检查

年龄门槛通常要落在主题的真实页面路径中。使用 theme app extensions 可以减少直接改主题代码的需要，并让商家在主题编辑器中配置 app blocks 或 app embed blocks 的位置。不过，易于放置不等于覆盖完整。每个页面模板、商品范围和设备状态都要经过检查。

App embed 与 app block 各自解决什么

App embed 更适合跨页面的入口、遮罩或脚本接入；app block 更适合在特定模板位置放置提示或状态。实际效果取决于主题结构和应用能力，不能假设任何应用都能覆盖所有路径。需要阻挡某些商品时，还要确认模板、动态导航、推荐模块和深链接是否会绕过入口。

主题编辑器中的开关、位置和范围应与店铺的产品矩阵对应。若团队为普通页面打开了全站遮罩，应重新判断是否真的需要；若只在首页放置组件，则应测试访客跳过首页的路径。修改主题前应保留可恢复的配置记录，并让人工负责人知道当前有效范围。

以失败为中心做验收

验收不应只截一张“通过”页面。至少要检查首次进入、拒绝、超时、返回、刷新、深链接、普通内容、受限商品、移动端和禁用脚本等状态。每一种状态都应写下预期页面、可见文案、是否允许下一步以及人工入口。

如果主题或应用更新后遮罩覆盖了政策页和联系页，用户就无法获得说明或请求帮助。安全回退不是把遮罩全部关闭，而是让受限商品继续阻断，同时恢复必要的政策、联系和普通内容路径。

Shop 渠道资格要单独核对

Shop 渠道有自己的产品资格和展示要求。官方资料明确列出年龄限制产品、酒精、烟草、赌博等示例，以及药品、医疗器械、成人内容等其他类别；这属于 Shop 渠道的产品限制事实，不是 Online Store 前台的全部年龄验证规则。

Online Store 门槛不等于 Shop 资格

店铺可以在 Online Store 前台设置访问门槛，但这并不自动说明相关商品符合 Shop 渠道资格。反过来，某商品是否能在 Shop 展示，也不等于 Online Store 必须采用同一种前台流程。两个问题要分别放进发布清单：前台能否正确阻断，以及渠道是否允许该产品和配置。

检查年龄验证应用的兼容性说明

Shopify 的 Shop 展示要求页举例说明某些密码控制或年龄验证应用可能影响 Shop 展示资格，也提到特定例外。资料卡同时明确，不能外推为所有年龄验证应用都不兼容，也不能保证换成某个应用就能进入 Shop。店铺应按最新官方资格页逐项复核应用、产品、市场和店铺状态。

如果核对结果不确定，先缩小 Shop 曝光范围或暂时撤下受影响商品，再由负责人确认，不要把渠道资格问题隐藏在前台弹窗之后。任何对 Shop 的判断都应记录检查日期、页面版本和适用范围，因为渠道要求可能独立于 Online Store 的主题配置发生变化。

商品范围结果与前台状态要分开

前台阻断可以避免用户继续浏览受限内容，但它不是所有商品范围判断的唯一安全边界。商品推荐、集合页、搜索结果、直接链接和不同市场的页面状态都可能是不同的处理点。这里要明确：前台状态不能单独承担所有范围判断，受限范围必须在每个入口保持一致。

不要信任一个全局浏览器布尔值

一个名为“已通过”的 cookie 或本地状态，可能来自普通页面、旧版本规则、共享设备或被清理前的历史会话。它不能自动覆盖不同商品和市场。若业务流程需要在后续步骤再次判断，应使用受限范围、会话时间和明确结果，而不是把全站状态当成永久通行证。

让受限商品默认不放行

当判断缺失、过期、矛盾或无法解释时，应回到受限状态。可以保留普通内容和客服路径，但不应因为用户已经完成某个页面按钮就自动解除受限商品的阻断。验证结果也不应从浏览器直接被当作可信证明交给所有下游页面。

这并不意味着每一次访问都要重复最重流程。店铺可以设计受限范围内的短期会话和清晰的重新判断条件，只要失效、范围变化和服务异常时都有安全回到阻断状态的路径。规则越简单，人工越容易复核。

人工接管与日常处置

人工接管不是让工作人员随意放行，而是给异常提供可追踪、有限制的处理路径。需要接手的情况包括第三方服务不可用、访客结果不一致、市场无法确认、误拦截普通内容、用户提出隐私问题，以及渠道资格检查出现冲突。

触发条件要能被识别

每个触发条件都应对应一个页面状态或记录标记，例如“验证超时”“待审”“范围不明”“用户拒绝”“店铺规则待确认”。不要用模糊的“联系客服看看”替代条件。触发后，受限内容保持隐藏，访客看到下一步和预计响应方式。

人工只接收必要信息

处理人需要知道产品或页面范围、市场判断、验证状态、发生时间和用户提出的问题，通常不需要看到完整证件资料。若第三方服务提供唯一参考号，也应评估是否有必要保存，避免把可识别信息复制到多个系统。人工决定要有理由、时间和复核条件。

关闭门槛也要有安全路径

当店铺需要暂停某个应用、产品或渠道时，安全做法是先撤除受影响范围的曝光，恢复政策页、联系页和普通内容，再由人工确认后恢复。不能为了避免前台报错而把受限商品静默放开。暂停期间，客服文案应说明服务正在检查，而不是声称验证已经完成。

失败与回退案例：全站弹窗冲突 Shop 资格

设想一个店铺把年龄门槛做成全站弹窗，并同时接入 Shop。测试复核发现，所用验证配置可能与 Shop 展示资格要求发生冲突；同一时间，前台脚本故障导致政策页和联系页也被完全遮挡。这个假设场景的重点不是归咎某个应用，而是说明“渠道资格”和“前台可用性”需要两套独立的止损判断。

触发条件

触发条件有两个：第一，Shop 官方要求核对后发现当前年龄验证或密码控制配置可能影响展示资格；第二，脚本超时或加载失败时，遮罩覆盖了所有页面，访客无法访问说明和人工入口。此时不能把失败状态解释成已完成验证，也不能等待用户反复刷新来碰运气。

用户影响

受限商品可能需要暂时停止 Shop 曝光；普通页面的访客无法理解为什么被挡住；有隐私疑问或误拦截的用户无法联系店铺；客服也无法依据完整状态判断问题来自主题、第三方服务还是渠道资格。若继续放行，风险是把未经确认的访问当成允许；若全部关闭，风险是把非受限内容一并变成空白页。

止损动作

先按商家自己的政策和适用规则，撤除受影响的 Shop 渠道或受限商品曝光；在 Online Store 保持受限商品阻断。随后恢复可访问的政策页、联系页和不受限内容，移除覆盖全站的故障遮罩或改为明确的暂停页。记录发生时间、影响范围、验证服务状态、主题配置和人工负责人，禁止通过删除 cookie 或写入“已通过”状态来绕过问题。

恢复验收

恢复前要分别验收 Online Store 和 Shop。Online Store 应覆盖首页、政策页、联系页、普通商品、受限商品、深链接、拒绝、待审、第三方超时、刷新和无脚本情形；受限内容在判断缺失时仍应阻断。Shop 则按最新官方资格页逐项核对产品和展示条件，不能用 Online Store 的截图代替渠道确认。

恢复完成的标准不是“弹窗重新出现”，而是四件事同时成立：普通访客能得到说明和帮助；受限商品不会因失败而放行；人工可以看懂并处理异常；Shop 的产品与展示资格有独立的复核记录。若任一项不成立，继续缩小曝光范围并保持人工处理。

发布前检查清单

发布清单应把产品、前台、数据、人工和渠道分别列出。每一项都要能回答“谁检查、检查什么、失败怎么办”，而不是只写“已安装应用”。这能防止门槛被误认为一个一次性装修动作。

页面与文案检查

确认门槛只出现在预定范围；说明清楚限制原因和下一步；拒绝或不确定不会进入受限内容；政策页和联系页在脚本失败时仍可访问；按钮不会把自我声明写成身份认证。移动端、键盘操作、对比度和错误提示也要检查，因为无法操作的门槛会造成不必要的误拦截。

技术与失败检查

直接打开受限商品 URL，模拟首次访问、已判断会话、过期会话、刷新、返回、换设备、清理站点数据、禁用脚本和第三方服务超时。确认主题 app embed 或 app block 的位置不会遮挡说明页，普通商品不会被错误归类，异常结果会回到阻断而不是放行。

隐私与人工检查

列出每个字段的用途、来源、访问人和保存时间；把 Customer Privacy API 的 consent 与年龄结果分开；确认第三方服务返回的资料没有被不必要地复制；给客服一条明确的人工入口和处理条件。记录应足以解释决定，但不要为了“以后可能有用”而保留完整证件或精确位置。

Shop 检查

分别查看 Shop 的产品限制和展示要求。核对年龄限制产品、应用或密码控制配置、店铺状态和受影响市场。不要把“Online Store 已显示门槛”当成渠道资格结论，也不要把某个例外应用理解成所有店铺的保证。若无法确认，先保持缩小后的曝光和人工复核。

需要做主题组件和运营页面的整理时，可以参考 Shopify Polaris 组件库实战指南：如何让界面与官方设计系统保持一致；若需要进一步梳理实施范围或人工流程，可通过 WESWOO 服务 了解可获得的协助。参考资源不能替代商家对当前店铺配置和适用规则的核对。

运行后的监测与复核

年龄门槛不是配置完成后就永远不变。主题、应用、Shop 资格页、产品范围和目标市场都可能变化，因此应定期复核“受限内容是否仍然默认阻断”“普通内容是否仍然可访问”“人工入口是否仍然有效”。这里的监测重点是安全和可解释性，不是虚构通过率或效果承诺。

关注状态，而不是只看通过量

可以按时间记录入口次数、拒绝次数、待审数量、验证超时、误拦截反馈和人工处理耗时等运营信号，但这些数字不应被包装成合规证明。更有价值的问题是：哪些页面最常出现失败；是否有受限商品在没有有效判断时被展示；是否有人把普通内容误归入受限范围；人工是否能在不接触多余数据的情况下作出决定。

变化发生时重新做小范围验收

应用升级、主题替换、产品上新、市场扩展或 Shop 要求变化后，先在受影响范围重跑失败测试，再决定是否扩大开放。不要因为过去某次验收通过，就跳过深链接、禁用脚本和第三方超时的测试。小范围、可回退的调整更容易保留安全阻断。

如何把实施方案写成可执行的页面规则

一份好方案应让设计、开发、客服和负责渠道的人看到同一套范围和状态。每个页面规则应写出入口、受限条件、所需结果、失败文案、人工路径和恢复验收，不要只写应用名称。规则应通过清楚的页面状态和可见记录来执行，而不是依赖某个熟悉代码的人记忆。

用状态表代替模糊描述

状态表可以把“通过”拆成范围、时间和结果来源，把“失败”拆成拒绝、待审、超时和市场不明。这样，客服不会把用户的自我声明当作第三方结果，负责 Shop 的人也不会把 Online Store 的截图当成渠道凭据。

给每个状态安排出口

通过状态应有明确的可访问范围；拒绝状态应回到普通内容或联系页；待审状态应进入人工队列；服务不可用应保持阻断并显示暂停说明；规则不确定应由负责人核对产品和市场。没有出口的状态最后通常会被某个临时按钮绕过，所以必须在方案中提前写出。

FAQ

Shopify 是否有通用原生年龄验证功能？

不能这样概括。Shopify 的主题和应用扩展可以帮助店铺在 Online Store 中放置动态元素，但资料卡没有把它定义成适用于所有商品、市场和店铺的通用原生 age-gate。店铺应根据受限范围、验证强度和渠道要求选择方案，并单独验收失败路径。

自我声明什么时候可以使用？

自我声明只能作为产品层面的访问提示和分流。是否适合使用，取决于产品、市场、合作伙伴要求和适用规则，不能由一条统一承诺决定。它不等于身份或年龄的强证明；如果业务需要更强判断，应评估第三方流程，并在服务不可用时保持受限内容阻断。

Customer Privacy API 能不能证明访客年龄？

不能。Customer Privacy API 关注分析、营销、偏好和数据出售等处理是否获得许可，consent 不等于年龄证明。年龄门槛的判断和隐私同意应分别设计、分别说明，也不要把访客点击年龄提示理解成对所有数据处理的许可。

Online Store 设置了门槛，就能在 Shop 展示受限商品吗？

不能自动推出这个结论。Shop 有独立的产品资格与展示要求，官方资料还提示某些年龄验证或密码控制配置可能影响展示资格。Online Store 前台是否阻断，和 Shop 是否允许某商品或配置，是两项独立核对；应按最新官方页面逐项复核，不能保证换用某个应用就一定符合要求。

第三方验证服务故障时，最安全的处理是什么？

默认保持受限商品和内容阻断，显示清楚的暂停或联系说明，并按范围撤除受影响渠道或商品曝光。人工负责人可以核对服务、主题、市场和产品范围；不要静默跳过验证，也不要把浏览器 cookie 或一个通过值当作永久证明。恢复前要重新测试通过、拒绝、待审、超时、深链接和无脚本路径。

官方一手来源与事实限定

以下链接只用于核对 Shopify 的平台政策、帮助中心说明和开发文档。它们不能替商家作出具体地区的法律判断，也不能保证某个应用、产品或市场一定获得资格。年龄门槛不是法律意见；Shop 渠道资格与 Online Store 前台门槛必须分别复核；应用、主题和官方要求发生变化时，应以届时的官方页面和店铺实际配置为准。

• Shopify Acceptable Use Policy：用于理解商家需同时遵守经营地、目标市场、合作伙伴及相关规则的上游边界，不是年龄验证实现指南。
• Shopify Help Center：Ensuring that your store complies with Shopify's policies：用于建立发布前核对清单，并提醒商家按司法辖区核对、必要时咨询自己的法律顾问，不是统一合规结论。
• Shopify Help Center：Prohibited products on Shop：用于核对 Shop 的产品资格限制，不代表 Online Store 的全部门槛规则。
• Shopify Help Center：Requirements for displaying your store in Shop：用于核对 Shop 展示兼容性；页面中的应用示例和例外不能外推成所有应用的保证。
• Shopify Dev：About theme app extensions：说明 app blocks 与 app embed blocks 的主题集成方式，不是服务端年龄证明或法律认证。
• Shopify Dev：Customer Privacy API：说明隐私处理许可的用途；其中的 consent 不能当作年龄证明。