Chrome Web Store 对扩展政策做了几处收紧，最容易影响开发团队的是用户数据。扩展只能收集、使用或传输和单一用途有关的数据，数据收集要显著披露，后续处理方式变化也要主动告诉用户。做浏览器扩展的人，得把权限和数据流重新翻一遍。
单一用途要能落到代码
Chrome 的 Limited Use 规则强调一个点，扩展的数据处理必须服务于已经披露的单一用途。这个要求听起来像法务语言，落到代码里就是权限、content script、后台脚本、远端 API 和埋点都要能解释。
举个常见场景，扩展主功能是网页批注，却顺手采集完整浏览历史做推荐。用户在商店页看到的是批注工具，代码里跑的是画像管道，风险就很高。工程团队需要把 manifest 权限、host permissions、网络请求和服务端字段放在同一张表里看。
显著披露别藏在隐私政策里
Chrome 的披露要求说得很直接，处理用户数据前要让用户看到会收集什么、怎么使用，并取得明确同意。只把说明塞进隐私政策链接里不够。扩展内的弹窗、设置页、首次引导和权限请求文案都要和实际数据流一致。
这里最容易出错的是功能迭代。产品后来加了同步、团队协作、AI 摘要或错误上报，数据处理范围变了，但旧的披露文案没跟上。审核看到的是文案，事故发生时看的是日志和接口。两边对不上，解释成本会很高。
权限最小化要做成清单
扩展开发经常为了省事申请宽权限，比如所有站点访问、tabs、cookies、history。新政策环境下，这些权限要逐项说明用途。能用 activeTab 就别要全站访问，能用 optional permissions 就不要一安装就让用户接受全部权限。
建议给每个权限写三列，用户可见功能、触发条件、数据去向。没有用户可见功能的权限，先删。触发条件写不清的权限，改成用户主动开启。数据去向说不明白的权限，先停远端传输。这个表比一长段合规说明更有用。
AI 护栏绕过扩展会被盯上
这次更新还把绕过 AI 服务安全护栏、使用限制或保护措施的扩展列为不允许的产品类型。对前端团队来说，别把提示词注入、批量自动化、反检测脚本包装成生产力工具。平台已经把这类边界写进政策。
如果扩展确实接入模型服务，建议把用途限定得更窄。输入来自哪里，是否包含网页内容，是否上传到第三方，是否保留原文，用户能不能关闭，都要说清楚。技术上还要给敏感字段做本地过滤，至少让默认路径别把令牌、邮箱、客户资料直接带出去。
优易云的落地建议
扩展团队可以安排一次小型过账。拉出 manifest、后台脚本、content script、远端 API、埋点 SDK、错误上报和隐私文案，把每条数据从浏览器走到服务端。每个字段都标出来源、用途、保留时间和第三方接收方。
然后再改产品。权限改窄，披露前置，数据处理变化加提示，AI 相关功能加开关和本地过滤。别等审核失败才临时删代码。扩展的信任来自很细的地方，少拿一个权限，少传一个字段，用户会少一点疑心。
