《互联网应用个人信息收集使用管理办法（征求意见稿）》解读——个人信息搜集监管加码
2026 03/10
2026年1月10日，中国国家互联网信息办公室（CAC）发布《互联网应用程序个人信息收集使用管理办法（征求意见稿）》（以下简称“《征求意见稿》”）公开征求意见。该文件尝试整合、完善并重构此前分散在各类规范性文件中的监管要求。《征求意见稿》共计七章三十九条，以互联网应用程序为核心监管对象，详细规定了个人信息收集使用活动。同时，将软件开发工具包（SDK）运营商、应用分发平台运营商及智能终端制造商纳入统一监管框架。
一、互联网应用程序个人信息收集使用规则
互联网应用中个人信息收集与使用的规范主要见于第二章。虽然目前还是征求意见稿，但分析其条款所体现的监管方式与制度框架仍具有一定意义。
㈠个人信息披露机制的“结构化清单”要求
《征求意见稿》第七条规定，运营者应通过结构化清单披露个人信息情况。这一做法与监管机构近年来倡导的“清单式披露”趋势相契合。其中要求采用“结构化清单”和“逐项列明”不仅是为了方便用户理解，更是要求应用程序自身首先明确操作场景、所需权限、收集数据类型、收集频率、涉及的敏感信息以及对用户权利的潜在影响。企业在实施第七条及相关要求时，应优先考虑提升披露实践的一致性和可维护性，而非简单地增加新的清单体系。
㈡大型互联网应用规则更新的公示机制
《征求意见稿》第八条对大型互联网应用更新个人信息规则制定了严格的公示程序。更新内容必须通过应用首页、官方网站等渠道公开征求意见，且公示期不得少于7个工作日。这一规定与《电子商务法》及《网络交易平台规则监督管理办法》中的信息披露要求相衔接，充分体现了对用户知情权和参与权的高度重视。
㈢初次索取授权的底线原则
《征求意见稿》首先确立了‘收集前弹窗’的原则，规定用户必须点击‘同意’后方可进行数据采集。其次，应用程序不得在用户拒绝非必要权限后强制获取同意，也不得拒绝核心服务或频繁骚扰用户。最后，应用程序仅在用户实际使用特定功能时才可请求对应权限，严格禁止预先获取权限。
㈣高风险权限访问限制
《征求意见稿》对接触列表访问、通讯录、通话记录和短信等高风险权限实施严格管控。虽然表面上涉及权限管理，但其核心关注点并非单纯是否要授予应用用户的联系人权限，而是确定应用所收集数据的预期用途。该条款的关键重点并非授权本身，而是其适用范围的界定。它明确禁止将此类数据用于分析非用户社交网络。
个人位置数据仅限导航和外卖应用以最低服务频率实时访问。其他操作（如添加或搜索地址）仅在界面打开或刷新时访问一次。严禁后台位置追踪。
此外，人脸、指纹和声纹等生物识别数据因其高度个人化特征，应妥善存储于终端设备中，未经用户明确授权不得通过互联网传输至外部。同时，数据保留期限不得超过最低必要时限。
㈤最小必要原则与情境式授权
个人信息的收集必须与应用程序的实时场景动态匹配，权限应在场景结束后立即撤销。即使场景需要，若智能终端的内置存储访问框架能够处理传输的，也不应调用相关权限。若应用确实需获得访问存储权限，也仅应读取用户选定的文件或文件夹，严禁扫描其他内容。整个收集过程必须始终遵循最小原则。
除应用运营商外，《征求意见稿》还对SDK运营商和智能终端制造商提出了相应的具体要求。SDK需与应用运营商协作，建立基于使用功能的个人信息收集与配置管理机制；智能终端制造商则须在设备设计初期就完成细粒度的个人信息收集授权机制。
二、不同主体的主要合规义务
《征求意见稿》在总则部分确立了适用于各类主体的合规原则框架，如合法性、正当性必要原则；告知与同意原则；最小必要原则及拒绝权保障原则以及国家秘密与通信秘密保护原则。在此基础上，《征求意见稿》进一步针对不同实体引入差异化特殊义务，核心要点如下：
㈠APP运营商
1.告知同意强化
该意见稿明确了三种类型的同意告知要求：(1)初始使用时弹窗告知；(2)增加一键访问功能；(3)强调隐私政策修改时重新获取同意。《征求意见稿》规定互联网应用程序必须在对隐私政策进行重大修改时（符合第八条第一款情形的），通过弹窗或推送通知告知用户重新获取同意。隐私政策修订通常发生在两种情形下：一是遵守监管要求、法律标准，二是个人信息处理方式发生重大变化。
2.大型互联网应用程序公开征求意见触发机制
《征求意见稿》要求大型互联网应用程序（定义为注册用户超过5000万或月活跃用户达1000万以上，业务类型复杂的互联网应用程序）修订、更新其个人信息收集使用规则，应向社会公开征求意见，且征求期限不得少于7个工作日。隐私政策作为个人信息保护的基础性工具，同时也是数据处理方对外展示其处理情况并明确责任的关键法律工具。通过强制要求规则更新进行公开征询，提升公众参与度，确保隐私政策的公平性、合理性和透明度。
对比下，针对非大规模互联网应用，《征求意见稿》要求其发布或更新版本后，必须采取有效措施通知用户进行升级，同时要求通过授权渠道分发的所有过时版本均须更新替换。
3.明确禁止性条款
《征求意见稿》明确规定，互联网应用程序不得获取用户个人资料之外的信息，例如联系人列表、通话记录和短信权限。该条款仅允许在特定场景下使用数据收集，例如确实需要管理联系人、添加好友或创建备份时。这是首次针对通过用户收集第三方个人信息的情况（特别是涉及联系人列表的情形）作出的立法回应。企业调用用户的通讯录即收集了其他人的个人信息，但由于用户本身不被视为个人信息处理方，因此无法援引个人数据转移的法律原则。这在实践中形成了监管灰色地带。意见稿对这类场景的明文禁止不仅建立了监管框架，还回应了公众对通信隐私保护的关切。
4.用户权限保护:账号注销
《征求意见稿》第十八条规定了账号注销时个人信息收集及捆绑注销的相关事项。
(1)账户注销验证要求
在终止应用程序账户时，最小必要原则通常禁止收集面部识别或身份证信息等敏感个人信息。但实践中，存在账户被盗后注销或被不法分子（羊毛党）恶意注销等情况，因此现有监管规定对此给予了一定空间。这些条款允许在必要时收集此类敏感数据，以防范网络犯罪并确保安全管理。企业必须在完成账户注销或身份验证等既定用途后删除相关信息。
(2)捆绑注销方案
账户捆绑注销机制一直困扰着企业，由于统一账户系统内业务运营的高度关联性，单独取消账户存在实施难度。对此，《征求意见稿》提出了参考解决方案：对于同一企业实体或集团内采用统一账户管理系统的互联网应用，用户可选择在单一特定应用中取消账户或撤销用户在该应用中的使用权限，且仅删除与该应用相关联的个人数据。
5.涉及SDK的管理
《征求意见稿》针对互联网应用程序与用户直接互动的场景同样作出了规范。虽然用户通常不会感知或直接使用SDK，但这些应用程序与SDK之间可能建立涉及数据提供或联合处理的关系。《征求意见稿》要求应用程序及时通知SDK，并规定SDK必须及时回应用户请求。文件明确指出，SDK本身必须直接处理用户关于个人信息权利的请求，需在数据收集和使用政策中清晰制定有效机制和流程。《征求意见稿》还要求应用程序与嵌入式SDK就个人数据收集和使用的用途、方法、类型及安全保护措施达成一致，并明确数据泄露的责任归属。此外，应用程序必须实施技术措施来审计SDK的数据收集和权限请求，确保其实际操作符合应用程序披露的规则。当用户请求查阅、复制、更正、删除、限制处理、注销账户或撤回与SDK活动相关的同意时，应用程序必须立即通知SDK并督促其响应。
㈡SDK安全运营管理要求
《征求意见稿》将软件开发工具包（SDK）定义为促进协助软件开发的软件库，其操作主体包括开发者、所有者、管理者或服务提供商。除涉及个人信息权利响应的义务外，《征求意见稿》还进一步明确了SDK需履行的三项关键义务：
→1.告知同意。《征求意见稿》要求SDK制定个人信息收集与使用规则，这些规则须在产品官网上公开披露，所有历史版本的规则也必须清晰列出。若个人信息处理的目的、方法或范围发生变化的，相关规则须相应更新。
→2.最小必要原则。《征求意见稿》明确规定，软件开发工具包（SDK）必须遵循最小必要原则，禁止收集或使用超出权限范围的个人信息，或未经授权访问权限。此外，SDK需符合自动化决策规定，并提供禁用此类功能的选项。
→3.配合互联网应用程序。《征求意见稿》规定，软件开发工具包（SDK）需根据功能需求配置个人信息选项，使互联网应用能够根据具体功能要求管理并配置SDK的个人信息收集行为。此举为互联网应用管理SDK提供了相应支持。
㈢分发平台运营商
该《征求意见稿》规定，分发平台是指通过互联网提供互联网应用程序发布、下载、动态加载等服务提供者，包括应用商店、应用市场、快速应用中心和小程序平台。同时，《征求意见稿》还明确了此类平台需履行的三项义务：
→1.上架审核义务。工信部《关于开展纵深推进APP侵害用户权益专项整治行动的通知》（2020年），要求应用分发平台公开应用信息并开展上架审核。实践中，应用商店已实施这些审核要求，且标准日趋严格。同时《征求意见稿》还明确规定了快速应用和小程序的审核义务。
→2.信息记录与披露义务。《征求意见稿》明确规定，分发平台须记录并披露互联网应用程序的历史违规记录，包括因非法收集或使用个人数据而被省级及以上个人信息保护主管部门通报或行政处罚的案例。对于存量互联网应用程序，《征求意见稿》要求分发平台在六个月内完成补充审查。
→3.配合义务。《征求意见稿》通过法律文件形式，正式确立了分发平台的配合义务，要求其在实施警告、拒绝分销、暂停分发或终止分发等措施时，须积极配合监管部门。此举可视为将行业惯例提升为法律规范。
㈣智能终端制造商
《征求意见稿》明确，智能终端是指能够接入公众网络、具有操作系统、可由用户自行安装和卸载应用软件的移动通信终端产品。除规定预装审查要求外，《征求意见稿》特别强调智能终端必须对互联网应用程序的权限进行管理，具体包括以下内容：
→1.权限管理。《征求意见稿》列明日历、通话记录、相机、通讯录、位置、麦克风、电话、短信、存储、身体活动等权限，要求智能终端必须在向互联网应用程序请求这些权限时，通过弹窗提示获取用户授权，同时提供基于时长、频率和精度等权限特点的细化授权选项。虽然实践中弹窗提示已经是权限请求的常见做法，但精细化授权则是一项新的合规要求。
→2.权限记录。《征求意见稿》要求智能终端需记录并集中展示互联网应用程序调用上述权限的情况，包括自应用程序启动以来通过智能终端收集剪切板、设备唯一标识、应用程序列表等行为的情况。
→3.权限披露。针对麦克风、摄像头及定位等高度敏感权限，《征求意见稿》要求智能终端在显眼位置（如屏幕顶部）进行提示，告知用户当前启用的权限使用情况。
三、合规行动指南
（一）文件更新：
现有隐私政策需全面修订为“结构化清单”格式，以清晰准确的方式完整逐项列出核心事项。对敏感个人信息收集声明、SDK相关说明及用户核心权利等关键部分，须通过加粗文本、放大字号和颜色编码等方式进行重点标注。
（二）过程公开：
若应用程序满足“注册用户5000万以上”“月活跃用户1000万以上”任一条件，或业务类型复杂，修订更新个人信息收集使用规则时，需通过公开渠道发起意见征求，征求意见期限不得少于7个工作日。
（三）交互式审核机制：
检查首次启动流程，确保“先弹窗告知，后同意收集”，移除“不点同意不让用”的逻辑设置，仅在充分披露信息后获取用户明确同意。对于非必要个人信息收集，应遵循“不同意不影响基本功能使用”原则。若后续规则更新涉及收集目的、方式或类型的重大变化，必须重新获取用户同意。
（四）供应链审计：
全面清查应用程序内嵌的所有软件开发工具包（SDK）；根据第十九条规定，与SDK运营方签署正式安全保护协议；并确保各SDK在其官方网站上发布独立的个人信息收集与使用规则（含不同历史版本的信息收集说明），同时在隐私政策中提供完整规则链接。
（五）用户响应：
账户注销流程需优化操作流程，使用户能自主停用特定应用账户并删除应用数据。投诉举报渠道须设置清晰易用的入口，建立完善的受理、处理及反馈机制。用户提交的注销申请须在15个工作日内完成全流程处理。
（六）其他：
控制逻辑“功能场景完成后权限终止”的技术实现。权限应在对应功能使用后立即终止，且不得在无关场景或后台静默调用。对于相册和存储权限，若需访问，其范围必须严格限定为仅读取用户主动选定文件，禁止访问超出功能核心范围的其他私密数据。
一、互联网应用程序个人信息收集使用规则
互联网应用中个人信息收集与使用的规范主要见于第二章。虽然目前还是征求意见稿，但分析其条款所体现的监管方式与制度框架仍具有一定意义。
㈠个人信息披露机制的“结构化清单”要求
《征求意见稿》第七条规定，运营者应通过结构化清单披露个人信息情况。这一做法与监管机构近年来倡导的“清单式披露”趋势相契合。其中要求采用“结构化清单”和“逐项列明”不仅是为了方便用户理解，更是要求应用程序自身首先明确操作场景、所需权限、收集数据类型、收集频率、涉及的敏感信息以及对用户权利的潜在影响。企业在实施第七条及相关要求时，应优先考虑提升披露实践的一致性和可维护性，而非简单地增加新的清单体系。
㈡大型互联网应用规则更新的公示机制
《征求意见稿》第八条对大型互联网应用更新个人信息规则制定了严格的公示程序。更新内容必须通过应用首页、官方网站等渠道公开征求意见，且公示期不得少于7个工作日。这一规定与《电子商务法》及《网络交易平台规则监督管理办法》中的信息披露要求相衔接，充分体现了对用户知情权和参与权的高度重视。
㈢初次索取授权的底线原则
《征求意见稿》首先确立了‘收集前弹窗’的原则，规定用户必须点击‘同意’后方可进行数据采集。其次，应用程序不得在用户拒绝非必要权限后强制获取同意，也不得拒绝核心服务或频繁骚扰用户。最后，应用程序仅在用户实际使用特定功能时才可请求对应权限，严格禁止预先获取权限。
㈣高风险权限访问限制
《征求意见稿》对接触列表访问、通讯录、通话记录和短信等高风险权限实施严格管控。虽然表面上涉及权限管理，但其核心关注点并非单纯是否要授予应用用户的联系人权限，而是确定应用所收集数据的预期用途。该条款的关键重点并非授权本身，而是其适用范围的界定。它明确禁止将此类数据用于分析非用户社交网络。
个人位置数据仅限导航和外卖应用以最低服务频率实时访问。其他操作（如添加或搜索地址）仅在界面打开或刷新时访问一次。严禁后台位置追踪。
此外，人脸、指纹和声纹等生物识别数据因其高度个人化特征，应妥善存储于终端设备中，未经用户明确授权不得通过互联网传输至外部。同时，数据保留期限不得超过最低必要时限。
㈤最小必要原则与情境式授权
个人信息的收集必须与应用程序的实时场景动态匹配，权限应在场景结束后立即撤销。即使场景需要，若智能终端的内置存储访问框架能够处理传输的，也不应调用相关权限。若应用确实需获得访问存储权限，也仅应读取用户选定的文件或文件夹，严禁扫描其他内容。整个收集过程必须始终遵循最小原则。
除应用运营商外，《征求意见稿》还对SDK运营商和智能终端制造商提出了相应的具体要求。SDK需与应用运营商协作，建立基于使用功能的个人信息收集与配置管理机制；智能终端制造商则须在设备设计初期就完成细粒度的个人信息收集授权机制。
二、不同主体的主要合规义务
《征求意见稿》在总则部分确立了适用于各类主体的合规原则框架，如合法性、正当性必要原则；告知与同意原则；最小必要原则及拒绝权保障原则以及国家秘密与通信秘密保护原则。在此基础上，《征求意见稿》进一步针对不同实体引入差异化特殊义务，核心要点如下：
㈠APP运营商
1.告知同意强化
该意见稿明确了三种类型的同意告知要求：(1)初始使用时弹窗告知；(2)增加一键访问功能；(3)强调隐私政策修改时重新获取同意。《征求意见稿》规定互联网应用程序必须在对隐私政策进行重大修改时（符合第八条第一款情形的），通过弹窗或推送通知告知用户重新获取同意。隐私政策修订通常发生在两种情形下：一是遵守监管要求、法律标准，二是个人信息处理方式发生重大变化。
2.大型互联网应用程序公开征求意见触发机制
《征求意见稿》要求大型互联网应用程序（定义为注册用户超过5000万或月活跃用户达1000万以上，业务类型复杂的互联网应用程序）修订、更新其个人信息收集使用规则，应向社会公开征求意见，且征求期限不得少于7个工作日。隐私政策作为个人信息保护的基础性工具，同时也是数据处理方对外展示其处理情况并明确责任的关键法律工具。通过强制要求规则更新进行公开征询，提升公众参与度，确保隐私政策的公平性、合理性和透明度。
对比下，针对非大规模互联网应用，《征求意见稿》要求其发布或更新版本后，必须采取有效措施通知用户进行升级，同时要求通过授权渠道分发的所有过时版本均须更新替换。
3.明确禁止性条款
《征求意见稿》明确规定，互联网应用程序不得获取用户个人资料之外的信息，例如联系人列表、通话记录和短信权限。该条款仅允许在特定场景下使用数据收集，例如确实需要管理联系人、添加好友或创建备份时。这是首次针对通过用户收集第三方个人信息的情况（特别是涉及联系人列表的情形）作出的立法回应。企业调用用户的通讯录即收集了其他人的个人信息，但由于用户本身不被视为个人信息处理方，因此无法援引个人数据转移的法律原则。这在实践中形成了监管灰色地带。意见稿对这类场景的明文禁止不仅建立了监管框架，还回应了公众对通信隐私保护的关切。
4.用户权限保护:账号注销
《征求意见稿》第十八条规定了账号注销时个人信息收集及捆绑注销的相关事项。
(1)账户注销验证要求
在终止应用程序账户时，最小必要原则通常禁止收集面部识别或身份证信息等敏感个人信息。但实践中，存在账户被盗后注销或被不法分子（羊毛党）恶意注销等情况，因此现有监管规定对此给予了一定空间。这些条款允许在必要时收集此类敏感数据，以防范网络犯罪并确保安全管理。企业必须在完成账户注销或身份验证等既定用途后删除相关信息。
(2)捆绑注销方案
账户捆绑注销机制一直困扰着企业，由于统一账户系统内业务运营的高度关联性，单独取消账户存在实施难度。对此，《征求意见稿》提出了参考解决方案：对于同一企业实体或集团内采用统一账户管理系统的互联网应用，用户可选择在单一特定应用中取消账户或撤销用户在该应用中的使用权限，且仅删除与该应用相关联的个人数据。
5.涉及SDK的管理
《征求意见稿》针对互联网应用程序与用户直接互动的场景同样作出了规范。虽然用户通常不会感知或直接使用SDK，但这些应用程序与SDK之间可能建立涉及数据提供或联合处理的关系。《征求意见稿》要求应用程序及时通知SDK，并规定SDK必须及时回应用户请求。文件明确指出，SDK本身必须直接处理用户关于个人信息权利的请求，需在数据收集和使用政策中清晰制定有效机制和流程。《征求意见稿》还要求应用程序与嵌入式SDK就个人数据收集和使用的用途、方法、类型及安全保护措施达成一致，并明确数据泄露的责任归属。此外，应用程序必须实施技术措施来审计SDK的数据收集和权限请求，确保其实际操作符合应用程序披露的规则。当用户请求查阅、复制、更正、删除、限制处理、注销账户或撤回与SDK活动相关的同意时，应用程序必须立即通知SDK并督促其响应。
㈡SDK安全运营管理要求
《征求意见稿》将软件开发工具包（SDK）定义为促进协助软件开发的软件库，其操作主体包括开发者、所有者、管理者或服务提供商。除涉及个人信息权利响应的义务外，《征求意见稿》还进一步明确了SDK需履行的三项关键义务：
→1.告知同意。《征求意见稿》要求SDK制定个人信息收集与使用规则，这些规则须在产品官网上公开披露，所有历史版本的规则也必须清晰列出。若个人信息处理的目的、方法或范围发生变化的，相关规则须相应更新。
→2.最小必要原则。《征求意见稿》明确规定，软件开发工具包（SDK）必须遵循最小必要原则，禁止收集或使用超出权限范围的个人信息，或未经授权访问权限。此外，SDK需符合自动化决策规定，并提供禁用此类功能的选项。
→3.配合互联网应用程序。《征求意见稿》规定，软件开发工具包（SDK）需根据功能需求配置个人信息选项，使互联网应用能够根据具体功能要求管理并配置SDK的个人信息收集行为。此举为互联网应用管理SDK提供了相应支持。
㈢分发平台运营商
该《征求意见稿》规定，分发平台是指通过互联网提供互联网应用程序发布、下载、动态加载等服务提供者，包括应用商店、应用市场、快速应用中心和小程序平台。同时，《征求意见稿》还明确了此类平台需履行的三项义务：
→1.上架审核义务。工信部《关于开展纵深推进APP侵害用户权益专项整治行动的通知》（2020年），要求应用分发平台公开应用信息并开展上架审核。实践中，应用商店已实施这些审核要求，且标准日趋严格。同时《征求意见稿》还明确规定了快速应用和小程序的审核义务。
→2.信息记录与披露义务。《征求意见稿》明确规定，分发平台须记录并披露互联网应用程序的历史违规记录，包括因非法收集或使用个人数据而被省级及以上个人信息保护主管部门通报或行政处罚的案例。对于存量互联网应用程序，《征求意见稿》要求分发平台在六个月内完成补充审查。
→3.配合义务。《征求意见稿》通过法律文件形式，正式确立了分发平台的配合义务，要求其在实施警告、拒绝分销、暂停分发或终止分发等措施时，须积极配合监管部门。此举可视为将行业惯例提升为法律规范。
㈣智能终端制造商
《征求意见稿》明确，智能终端是指能够接入公众网络、具有操作系统、可由用户自行安装和卸载应用软件的移动通信终端产品。除规定预装审查要求外，《征求意见稿》特别强调智能终端必须对互联网应用程序的权限进行管理，具体包括以下内容：
→1.权限管理。《征求意见稿》列明日历、通话记录、相机、通讯录、位置、麦克风、电话、短信、存储、身体活动等权限，要求智能终端必须在向互联网应用程序请求这些权限时，通过弹窗提示获取用户授权，同时提供基于时长、频率和精度等权限特点的细化授权选项。虽然实践中弹窗提示已经是权限请求的常见做法，但精细化授权则是一项新的合规要求。
→2.权限记录。《征求意见稿》要求智能终端需记录并集中展示互联网应用程序调用上述权限的情况，包括自应用程序启动以来通过智能终端收集剪切板、设备唯一标识、应用程序列表等行为的情况。
→3.权限披露。针对麦克风、摄像头及定位等高度敏感权限，《征求意见稿》要求智能终端在显眼位置（如屏幕顶部）进行提示，告知用户当前启用的权限使用情况。
三、合规行动指南
（一）文件更新：
现有隐私政策需全面修订为“结构化清单”格式，以清晰准确的方式完整逐项列出核心事项。对敏感个人信息收集声明、SDK相关说明及用户核心权利等关键部分，须通过加粗文本、放大字号和颜色编码等方式进行重点标注。
（二）过程公开：
若应用程序满足“注册用户5000万以上”“月活跃用户1000万以上”任一条件，或业务类型复杂，修订更新个人信息收集使用规则时，需通过公开渠道发起意见征求，征求意见期限不得少于7个工作日。
（三）交互式审核机制：
检查首次启动流程，确保“先弹窗告知，后同意收集”，移除“不点同意不让用”的逻辑设置，仅在充分披露信息后获取用户明确同意。对于非必要个人信息收集，应遵循“不同意不影响基本功能使用”原则。若后续规则更新涉及收集目的、方式或类型的重大变化，必须重新获取用户同意。
（四）供应链审计：
全面清查应用程序内嵌的所有软件开发工具包（SDK）；根据第十九条规定，与SDK运营方签署正式安全保护协议；并确保各SDK在其官方网站上发布独立的个人信息收集与使用规则（含不同历史版本的信息收集说明），同时在隐私政策中提供完整规则链接。
（五）用户响应：
账户注销流程需优化操作流程，使用户能自主停用特定应用账户并删除应用数据。投诉举报渠道须设置清晰易用的入口，建立完善的受理、处理及反馈机制。用户提交的注销申请须在15个工作日内完成全流程处理。
（六）其他：
控制逻辑“功能场景完成后权限终止”的技术实现。权限应在对应功能使用后立即终止，且不得在无关场景或后台静默调用。对于相册和存储权限，若需访问，其范围必须严格限定为仅读取用户主动选定文件，禁止访问超出功能核心范围的其他私密数据。
