夜雨聆风
这次 30 款 App 通报，近一半的问题（14 款，47%）集中在同一件事上：账号注销。这意味着一个信号：监管的执法重心，正在从「你怎么收数据」转向「你怎么让用户离开」。
入口的功课——弹窗、隐私政策、权限索取——查了七年，大体收敛了。这份通报说明：监管正沿着用户数据的生命周期，从前门一路查到后门。
而且点名的措辞值得逐字读：不是"未提供注销功能"，是"未提供有效账号注销功能"。
"有效"两个字怎么验收？监管的办法很直接：亲手点一遍。这就是本期要反编译的全部逻辑。
① 监管事件 · 先钉死事实锚
· 通报对象：30 款 App，含小程序（28 款 App + 2 款小程序）
· 法律依据：《网络安全法》《个人信息保护法》《网络数据安全管理条例》《App违法违规收集使用个人信息行为认定方法》
· 上游行动：三部门《2026年个人信息保护系列专项行动》（2026-04-02 启动）
· 整改窗口：15 个工作日内完成整改并报网信办，核查后依法依规处置处罚
四类问题的分布，是这份通报最值得盯住的一组数字：
· 未公开个人信息收集使用规则：7 款（23%）——锐新教育、趣学车、莆田TV、画啦啦绘画天地（小程序）等
· 频繁索要非必要权限：4 款（13%）——蓝猫云商、大象优品、信小花、逸小花
· SDK 收集使用个人信息情况未完整准确列明：5 款（17%）——中旅旅行、东融、富小剧等
· 未提供有效账号注销功能：14 款（47%）——网易云阅读、匠者、i陪诊-用户端 等
完整名单见文末文件包里的通报原文明细表。下面拆它背后的四个信号。
② 监管逻辑 · 这份通报透出的四个信号
信号 1 ｜ 执法重心正从"入口"移向"出口"
近一半问题集中在注销，这不太像抽样巧合。把镜头拉长看：从 2019 年 App 专项治理算起，收集端的问题——隐私政策弹窗、首次启动采集、强制索权——已被连续多轮专项收敛；而退出端动的是真实成本：有效注销意味着真删数据、掉留存指标、断营销触达。入口整改是改交互，出口整改是动业务——所以它最慢，也就成了 2026 年暴露面最大的一道闸门。
一个合理的解读是：前门的功课大家交得差不多了，现在轮到后门验收。
信号 2 ｜ "有效"二字：监管开始实测，不再听汇报
《App违法违规收集使用个人信息行为认定方法》（2019 年四部门发布）早就把口径立在那里：设了注销入口但人为设置障碍、流程走不通、走完不删数据，都可能被认定为无效。这次通报的定性正是沿用这套口径——而"组织检测"的工作方式意味着：结论来自实测，不来自企业的自我陈述。
那监管是怎么测出来的？通报原文只有四个字："组织检测"。虽然通报未披露具体检测步骤，但结合历年公开检测标准、检测机构能力说明及行业实践，可以大致理解为以下三类检测能力：
· 静态检测：反编译安装包，比对实际集成的 SDK 与隐私政策列明项 → 对应"SDK 未完整准确列明"
· 动态检测：真机运行 + 流量与权限行为监测，看权限调用时序、声明外的数据外发 → 对应"频繁索权 / 未公开规则"
· 功能实测：注册 → 使用 → 注销，全流程人工走查 → 对应"未提供有效账号注销功能"
注意这里有个对称：监管在技术上"反编译"你的 App；本栏目反编译的，是监管的逻辑。所以企业自查的正确姿势不是读文件，是把监管这套测法在自己产品上先跑一遍——这也是下文两张清单的设计依据。
如果你看过本栏目第 1 篇（Temu €200M 案），会认出这是同一把尺子：欧盟用"神秘购物"实测平台上的违法商品，中央网信办用检测工具实测你的注销按钮。两边在同步切换到同一种执法姿势——有效性审查：不问你有没有制度、有没有功能，直接验证它真不真、通不通。
这就是本栏目反复说的「文件合规 → 证据合规」在国内执法侧的落地样本。
信号 3 ｜ 覆盖面三个细节：形态、体量、连坐
· 小程序首次以独立形态具名上榜（画啦啦绘画天地、麦田耕读）。通报对象写明"App（含小程序）"——别再把小程序当成合规检查的轻量豁免区。
· 大机构的长尾产品在名单里：中旅旅行（中国旅游集团）、网易云阅读（网易）、莆田TV（地方广电）。头部 App 合规资源充足，但集团产品线的长尾往往拿不到同等投入，这正是暴露位。
· 同一运营者两款产品同时上榜：南京诸夏文化传播（匠者 + 武者）、天津五双科技（富小剧 + 聚宝成语）。这透露检测是按运营者批量扫产品线的——一款产品的问题模式，大概率会在兄弟产品上被顺藤摸到。
信号 4 ｜ 法规堆栈已经换代，而且这只是"系列"的一发
依据列表里，《网络数据安全管理条例》（2025-01-01 施行）已进入常规引用位，与《个人信息保护法》《认定方法》组成"法律 + 行政法规 + 操作手册"的完整执法堆栈。更重要的是上游：这份通报是 2026 年 4 月三部门系列专项行动的产物——"系列"意味着这不是孤立事件，今年还会有下一批名单。你现在做的自查，对照的就是下一批的检测项。
③ 企业自查 · 四道闸门，监管在看什么
别人看名单，我们看监管的视线落点。通报的四类问题恰好是用户个人信息生命周期的四道闸门：告知 → 收集 → 共享 → 退出。本栏目只回答两个问题：监管在看什么、你该准备什么证据——"怎么改"是整改图纸栏目的事，这里不抢戏。
监管核查整改时，本质就是在逐条追问上面四块。"该备的证据"那一行拿不出来，整改报告写得再漂亮都是空头主张。
这四道闸门各自的工程整改方案——注销能力设计、删除能力设计、SDK 治理、权限治理——会在「整改图纸」栏目逐一展开，本篇不抢戏。
不要做这 4 件事
❌ 把"注销难"当留存策略。用流失指标换通报名单，这笔账在 2026 年的执法密度下大概率算不过来。
❌ 给注销条件层层加码。要求重新绑卡、上传手持身份证、等人工客服回访……"有效"测的是流程能不能走通——每加一道坎，都在向《认定方法》的"人为设置障碍"口径靠近。
❌ SDK 清单写"部分第三方服务"一笔带过。通报的措辞是"未完整准确列明"——模糊概括很可能本身就是命中项。
❌ 被点名后只改被点名那一条。检测是四道闸门全查 + 按运营者扫产品线，核查时大概率不会只看通报里那一行。
一页 Checklist · 15 个工作日的镜像测试
通报给被点名企业 15 个工作日整改。把它反过来用：假如今天被通报的是你，这四道闸门能不能在 15 个工作日内交差？答不上来的行，就是当下的整改项：
1. 新用户从首页找到隐私政策要几步？——入口前置、路径短、政策与实际收集一致（产品 + 法务）
2. 每个权限弹窗都能对应到一个正在使用的功能吗？——有权限-功能映射表，拒绝后有冷静期（客户端研发）
3. SDK 清单和当前版本实际集成的 SDK 一致吗？——台账全量、随版本发布同步更新（研发 + 合规）
4. 一个新注册账号，现在就走注销，几分钟能走完？——全流程可走通、无加码条件、有删除记录（产品负责人）
5. 上面 4 行的证据文件，今天能调出来吗？——每行至少一份可出示的留痕（合规）
监管已经不再问"你有没有注销功能"——而是亲手点一遍，看它通不通。
今天就做这 1 件事
拿一台干净的测试机，注册一个你自家产品的新账号，然后立刻走注销流程：计时、全程截图。
产出一页「出口体检单」：走没走通、几步、几分钟、卡点在哪、注销后数据怎么处理的。今天发给产品负责人。
走得通，这页纸就是你的审计证据；走不通——最好是你先发现，而不是出现在下一批通报的明细表里。
我们正在观察的三个信号
这期反编译留下三个开放变量，本栏目会持续追踪：
① 注销是否从"入口有效"走向"删除有效"——这次实测的是流程走不走得通；下一步，会不会核查注销之后数据有没有真删？
② SDK 披露是否从"有清单"走向"行为一致"——这次点的是"未完整准确列明"；下一步，会不会用动态检测比对清单与实际的数据外发？
③ 小程序是否会被要求达到与 App 同等的合规证明能力——查不查已经不是悬念（这次 2 款小程序具名），真正的变量是查到什么深度。
下一批通报出来，拿这三条对答案。
从隐私政策、权限弹窗，到账号注销、数据删除，监管正在沿着个人信息生命周期逐段验收。 合规的竞争，正在从"有没有制度"转向"能不能证明制度有效"。 当监管亲手点开你的注销按钮，真正接受测试的已经不是功能，而是企业的数据治理能力。
