「7月6日，最高法院放行」：德州 SB 2420（Bus. & Com. Code 第 121 章）即刻可执行——压在中资出海 App 开发者头上的五项义务，与犹他、加州的下两个硬性节点

2026年7月6日，美国联邦最高法院以简短、未署名、无异议记录的命令，驳回了 Students Engaged in Advancing Texas v. Paxton 与 Computer & Communications Industry Association v. Paxton 两案的紧急申请——申请人请求在上诉期间禁止德克萨斯州执行《应用商店问责法》（App Store Accountability Act，SB 2420）。最高法院没有触及第一修正案的实体争议，只回答了一个问题：上诉未决期间，这部法律要不要执行。答案是：要。

对任何通过 App Store 或 Google Play 向德州用户提供应用的企业而言，这意味着 Tex. Bus. & Com. Code 第 121 章自即刻起完全可执行，短期内不会有任何禁令救济。而其中最容易被中资出海企业忽略的，恰恰不是应用商店的义务，而是压在开发者头上的 B 分章（Subchapter C）义务——分级、变更通知、年龄核验、目的限制与强制删除。

一、从生效、被禁到复活：一条走了七个月的诉讼线

SB 2420 由德州第 89 届常会通过，2025年5月27日由州长 Greg Abbott 签署，新增《商业与商法典》第 5 编 C 分编第 121 章，法定生效日为 2026年1月1日。

2025年10月，CCIA（代表应用商店与开发者的行业协会）与学生团体 SEAT 分别提起诉讼。2025年12月，德州西区联邦地区法院 Robert Pitman 法官签发初步禁令（案号 1:25-cv-01660-RP 与 1:25-cv-01662-RP），认定该法以年龄验证和家长同意为条件限制应用商店内容访问，构成基于内容的言论限制，应适用严格审查（strict scrutiny），且因不分应用内容一概适用而不满足"窄幅裁剪"要求。德州总检察长当日提起上诉。

2026年5月28日，第五巡回法院合议庭中止（stay）了该初步禁令，认定德州在实体问题上有较强胜诉可能，并指出地区法院很可能适用了错误的审查标准——第五巡回认为本案涉及的是商业言论限制，应适用中度审查（intermediate scrutiny），而该法在中度审查下很可能成立：其要求"直接且实质地推进"德州保护儿童安全的重大利益，手段与目的之间存在"合理契合"。禁令中止后，该法自 2026年6月4日 起恢复执行。最高法院7月6日的驳回，则封死了短期内的救济通道。

二、应用商店端义务（§§121.021–121.027）

第一，年龄核验与四级分类。§121.021 要求：德州境内个人创建应用商店账户时，商店须以"商业上合理的核验方法"确定其年龄类别，分为四档——儿童（13岁以下）、低龄青少年（13–15岁）、高龄青少年（16–17岁）、成年人（18岁及以上）。法条并未界定何谓"商业上合理"。

第二，家长账户关联与逐次同意。§121.022 要求未成年人账户必须与经核验的家长/监护人账户关联，且家长须对每一次下载、每一次购买、每一次应用内购买单独同意。§121.026(a) 明确将"取得一揽子同意（blanket consent）授权多次下载或购买"列为违法行为——这一点与中国开发者习惯的"一次授权、长期有效"模式直接冲突。§121.022(f) 规定取得同意时须向家长披露：应用或购买项目及其分级、导致该分级的具体内容元素、相关个人数据的收集使用情况、以及开发者已采取的数据保护措施。§121.022(h) 为紧急服务等特定应用留出豁免。

第三，向开发者开放信号。§121.024 要求应用商店以"商业上可获得的方法"，允许开发者读取每一用户被分配的年龄类别，以及针对未成年用户是否已取得家长同意；§121.022(e) 要求家长撤回同意时通知相关开发者。这条看似是给开发者的便利，实际上是把"实际知悉（actual knowledge）"塞进了开发者手里——后文详述其连锁风险。

第四，数据最小化与加密。§121.025 要求商店仅收集处理年龄核验、取得同意及留存合规记录所必需的最小限度个人数据，并以行业标准加密协议传输。

三、开发者端义务：中资出海企业的真正主战场（§§121.051–121.056）

§121.051 界定适用范围：凡通过应用商店向德州用户提供应用的开发者，一律适用，没有营收门槛、没有用户规模门槛、没有"主要面向儿童"的限定。一款工具类、天气类、跨境电商类应用同样在内。

1. 分级义务（§121.052）。开发者须依 §121.021(b) 的四档年龄类别，对应用本身以及应用内每一项可购买内容分别指定分级，并向每一个分发该应用的商店提供分级结果以及导致该分级的具体内容或元素。对内购 SKU 动辄上百项的中资游戏与电商应用，这是一项台账级工作量。

2. 重大变更通知义务（§121.053）。开发者在对应用的服务条款或隐私政策作出"重大变更"前，须事先通知每一个分发商店。法条列举四类触发情形：（一）开发者收集、存储或共享的个人数据类型或类别发生变化；（二）影响或改变 §121.052 项下分级、或改变导致该分级的内容元素；（三）新增变现功能，包括新的应用内购买机会或新的应用内广告；（四）实质改变应用的功能或用户体验。商店收到通知后，须依 §121.022(g) 重新向已同意的家长取得同意。这是中国研发流程最容易漏掉的一环——国内迭代节奏快、灰度发布频繁，而这里要求的是"发版前通知"。

3. 年龄核验系统义务（§121.054）。开发者须建立并实施一套系统，使用 §121.024 项下从商店获得的信息，核验每一用户的年龄类别，并就每一未成年用户核验是否已取得家长同意。注意措辞是"create and implement a system"——不是"参考"，而是要有可审计的工程实现。

4. 目的限制与强制删除（§121.055）。开发者对商店提供的个人数据，仅可用于三项用途：执行与年龄相关的限制与保护措施、确保遵守适用法律法规、实施安全相关功能与默认设置。且 §121.055(b) 要求：核验完成后即须删除该数据。这意味着年龄类别信号不得回流至广告投放、推荐算法或用户画像系统，也不得共享给关联公司或境外母公司。

5. 违法情形与两道安全港（§121.056）。开发者的违法行为包括：对未依 §121.054 取得同意的未成年人执行合同或服务条款、明知而虚报分级或分级理由、以及泄露依本分章取得的用户个人数据。安全港有二：其一，若开发者采用广泛采纳的行业标准确定分级并善意、一贯地适用，则不因 §121.052 承担责任；其二，若开发者善意信赖应用商店提供的年龄类别与同意信息且已另行遵守本条要求，则不因 §121.054 承担责任。

四、责任后果：DTPA 通道意味着什么

§121.101 规定，违反第 121 章即构成《德州欺骗性商业行为—消费者保护法》（DTPA，商业与商法典第 17 章 E 分章）项下的欺骗性商业行为，并可依该分章追责。这条"接线"的杀伤力在于：它同时打开了公权与私权两个通道。总检察长可依 §17.47 申请禁令并主张民事罚款（每次违法行为最高 10,000 美元，针对 65 岁以上消费者的另加最高 250,000 美元）；消费者亦可依 §17.50 提起私人诉讼主张经济损失，明知（knowingly）者可加判精神损害赔偿并最高三倍经济损失，故意（intentionally）者可再加重。§121.103 另行确认本章救济为累积性，不排除其他法律项下的诉因。

五、不止德州：三州立法与全国版图

犹他州是第一个修正自身应用商店问责法的州。2026年3月18日，州长签署 HB 498，对 2025 年 SB 142 作出重大修改：核心运营义务的合规日期推迟一年至 2027年5月6日；删除总检察长的执法权，仅保留私人诉权——受害儿童的家长可提起民事诉讼，主张实际损失与"每次违法 1,000 美元"两者中的较高者，另加诉讼费用。修法同时收窄了"重大变更"定义（剔除"功能与用户体验变化"，但明确纳入新增内购或广告），新增开发者可主动请求商店禁止未成年人下载其应用的选项，并将年龄类别数据的可用目的限缩为三项、禁止向任何第三方共享。行业协会的诉讼已于 2026年4月21日自愿撤回。

加利福尼亚州走的是另一条路。AB 1043《数字年龄保证法》（Digital Age Assurance Act）于 2025年10月13日签署，2027年1月1日生效：要求操作系统提供商在设备账户设置环节收集出生日期或年龄，并通过实时 API 向请求信号的开发者提供用户所处年龄区间信号。该法刻意回避内容限制，只搭建"年龄信号基础设施"，从而规避第一修正案质疑——但对开发者而言，结果同样是"你将收到一个你以前没有的年龄信号"。路易斯安那州亦已通过类似立法。

值得注意的信号是：在最高法院的两案中，共有 27 位州总检察长提交法庭之友意见书支持德州。这基本预示了 2027 年立法季会有更多州跟进。

六、被低估的连锁风险：从"收到信号"到"实际知悉"

SB 2420 最深远的影响，可能不在第 121 章本身，而在它触发的其他法律。§121.024 让开发者获得每一用户的年龄类别——一旦你知道某用户在 13 岁以下，你就对该用户具有 COPPA 意义上的"实际知悉"，从而触发《儿童在线隐私保护规则》（16 C.F.R. Part 312）项下的可验证家长同意、披露、留存限制等全套义务，即便你的应用原本定位为面向一般受众。同理，多个州的青少年隐私条款以"实际知悉用户未满 18 岁"为触发条件。

另一重张力在于与数据最小化原则的正面冲突：第 121 章要求开发者接收、确认并处理原本不会收集的年龄与同意数据；而各州综合隐私法与 PIPL 均以最小必要、短期留存为原则。§121.055(b) 的"用完即删"某种程度上是立法者对此张力的缓冲，但工程上必须真正落地——保留一份"以防万一"的年龄类别副本，本身就是违法行为。

七、对中资企业的合规要点

第一，先做适用性判断，且不要只看 Apple 与 Google。§121.002 对"app store"的定义是"向移动设备用户分发软件应用的任何公开可用网站、软件应用或其他电子服务"，无规模或营收门槛。第三方安卓商店、企业分发平台、SDK 分发渠道、乃至自建下载页，都可能落入定义。中资手机厂商自有商店尤其应当自查。

第二，建立内购分级台账。不只应用本体，虚拟货币、道具、皮肤、会员订阅、开箱机制等每一项可购买内容都需单独分级，并留下"哪些内容元素导致了该分级"的书面说明。这份说明将来既是 §121.052 的合规文件，也是 §121.056(b) 安全港的证据。

第三，把 §121.053 的四类触发情形写进发版流程。建议在版本发布 checklist 中固化四道问答：本次是否改变了收集的个人数据类型？是否影响分级或分级理由？是否新增内购或广告？是否实质改变功能或用户体验？任一为"是"，则发版前必须向所有分发商店发出通知。注意德州仍保留"功能或用户体验实质变化"这一触发项，而犹他修法后已将其剔除——两州标准不一致，应按更严的德州标准统一执行。

第四，接入年龄信号 API 的同时，同步落地目的限制与删除。接入 Apple 的 Declared Age Range 类接口或 Google Play 的年龄信号接口时，须在数据流设计上确保年龄类别数据不进入广告、推荐、增长、风控画像等下游系统，不写入用户主档，不随数据出境流向境内母公司，并在核验完成后按 §121.055(b) 删除。这一点应写入 DPA 与内部数据流图，并可被审计。

第五，主动构建安全港证据链。§121.056(b)(c) 的两道安全港以"善意"与"一贯适用"为前提，实务上意味着：保留分级标准文档及其版本历史、API 调用与信号接收日志、家长同意状态查询记录、变更通知的发送凭证。中资企业在美诉讼中最常见的失分点，不是没有做，而是做了却证明不了。

第六，并行评估 COPPA 与中国法。德州规则与 PIPL 第 31 条（处理不满十四周岁未成年人个人信息须取得父母或监护人单独同意）及《未成年人网络保护条例》并不冲突，但技术路径不同：中国路径重"单独同意 + 专门规则"，德州路径重"商店代为核验 + 逐次同意 + 用完即删"。两套体系需要在同一套代码里共存，而不是二选一。

八、格知律所如何协助

格知律师事务所在数据合规领域为中资出海企业提供覆盖立法映射到争议应对的全流程服务。就本文议题，我们可协助：（一）应用分发合规评估——将德州第 121 章、犹他 ASAA（经 HB 498 修正）、加州 AB 1043 与路易斯安那州规则映射为一张统一的义务矩阵，识别贵司真实的适用范围与最严标准；（二）分级台账与分级说明文本撰写，包括应用与内购项目的分级方法论文档，使其足以支撑 §121.056(b) 的行业标准安全港；（三）发版"重大变更"通知 SOP 设计，将法定触发情形嵌入研发与发布流程，并起草致应用商店的标准通知模板；（四）年龄信号数据治理意见，就 §121.055 目的限制与强制删除出具工程可执行的数据流设计建议，并同步审查供应商 DPA 与跨境传输安排；（五）COPPA 与州青少年隐私法的连带风险评估，处理"实际知悉"触发后的可验证家长同意方案；（六）争议应对——DTPA 项下总检察长调查与民事罚款的应对、犹他私人诉权项下集团诉讼的抗辩与和解策略，以及安全港证据链的诉前梳理。我们同时协调中国《个人信息保护法》与《未成年人网络保护条例》项下的对应义务，避免企业在两套体系间出现合规冲突或重复建设。

九、结语与展望

需要清醒的是：最高法院 7 月 6 日的命令不是终局判决。第一修正案的实体争议已发回第五巡回法院审理德州对原初步禁令的上诉，未来仍可能出现相反结论。但对企业而言，"法律可能日后被推翻"从来不是不合规的理由——在中止期间发生的违法行为，同样可以被追究。

更值得关注的是趋势的方向。最高法院 2025年6月27日在 Free Speech Coalition v. Paxton 中维持了德州针对成人内容网站的年龄验证法，为各州的年龄门槛立法提供了宪法层面的信心；27 位州总检察长的联署，则表明这一模式正在向全国扩散。2027年1月1日（加州 AB 1043）与 2027年5月6日（犹他 ASAA）是接下来两个硬性节点，距今分别为 142 天与 267 天。对中资出海的应用开发者而言，德州已经不是"要不要做"的问题，而是"能否在下一个发版周期前把分级台账、变更通知与信号治理这三件事做完"的问题。