上架资料里的隐私政策 URL 看起来只是一个文本框，真正容易失控的却是它背后的发布链：域名切换、CDN 重定向、旧页面缓存、中文路径回退、内容运营误改名称，都可能让一个“昨天还能打开”的地址在提交当天变成错误页面。

本文把这类问题收束成一个可复用的发布前检查器。示例项目叫 PolicyProbe，页面叫 PrivacyAuditPage，任务编号固定为 POLICY-LINK-0081。演示数据以“星账本”为例：入口地址为 https://privacy.example.com/ledger/zh，允许最多 3 次跳转，正文上限 512 KB，最终页面必须同时出现应用名称、开发者名称和生效日期三个身份标记。

文中的状态、耗时与摘要值用于说明验证逻辑，不冒充真实商店审核结论，也不代表某个线上域名已经通过审核。检查器只能证明本次探测满足团队设定的门禁，不能替代平台审核。

一、真正需要检查的不是“有没有填 URL”

很多团队把隐私政策链接当成发布资料的一部分，直到提交前才由运营人员点开一次。这样的检查只能覆盖“当前浏览器能否显示页面”，无法回答四个更具体的问题。

第一，访问链是否稳定。入口可能经历 HTTP 到 HTTPS、裸域到 www、语言路由和活动页跳转。每增加一层跳转，就增加一次证书、DNS、缓存或规则配置出错的机会。示例门禁把最大跳转次数设为 3，不是宣称平台存在同样的硬限制，而是给团队一个可执行的风险阈值。

第二，最终页面是不是预期页面。状态码 200 只说明服务器返回了内容，可能返回统一错误页、登录页、机器人验证页，甚至另一个应用的隐私政策。只判断状态码会把“能打开”和“内容正确”混为一谈。

第三，页面身份是否与待发布版本一致。示例发布资料中的应用名称是“星账本”，开发者是“北京游记科技有限公司”，隐私政策生效日期是“2026-09-18”。页面若仍写“星账本 Pro”或旧公司名称，技术上可达，审核资料却出现了语义冲突。

第四，检查能否复现。人工截图很难回答当时经过了几次跳转、最终地址是什么、正文摘要是否变化。我们需要一份结构化报告，让构建任务、发布负责人和后续排查使用同一组事实。

因此，PolicyProbe 不把 URL 检查写成一个布尔函数，而是设计为状态机：QUEUED → FETCHING → VALIDATING → BLOCKED/PASS。修复后重新检查时再进入 RECHECKED → PASS。每个状态都保留时间、地址、状态码和发现项，避免界面只显示一个没有上下文的红叉。

二、先把可变的规则从脚本中拿出来

一个常见坏味道是把应用名称、域名和跳转次数直接写死在抓取函数里。这样做在单应用仓库里很快，多模块或多品牌共用脚本时却很难审查差异。更稳妥的做法是让发布元数据和探测规则进入同一个清单。

这段代码解决什么问题：用类型明确的清单固定待检查 URL、内容身份和网络边界，避免脚本里的散落常量。

// tools/policy-probe/config.ts
export interface PolicyProbeConfig {
  taskId: string
  entryUrl: string
  allowedFinalHosts: string[]
  maxRedirects: number
  maxBodyBytes: number
  requiredMarkers: string[]
}

export const config: PolicyProbeConfig = {
  taskId: 'POLICY-LINK-0081',
  entryUrl: 'https://privacy.example.com/ledger/zh',
  allowedFinalHosts: ['privacy.example.com'],
  maxRedirects: 3,
  maxBodyBytes: 512 * 1024,
  requiredMarkers: [
    '星账本',
    '北京游记科技有限公司',
    '2026-09-18'
  ]
}

这里把 requiredMarkers 做成数组，而不是三个专用字段，是为了让不同产品增加客服联系地址、SDK 清单标题等自定义标记。它并不意味着只要出现关键词就一定合规；关键词匹配只是内容身份的低成本防错层，法律文本仍需由负责人员确认。

allowedFinalHosts 防的是“入口域名看起来正确，最终却跳到了别处”。实际项目不要用字符串后缀草率判断域名，例如 evil-example.com 并不是 example.com 的子域。应解析 URL 后比较完整主机名，若允许子域，也要以点边界进行匹配。

maxBodyBytes 则用于保护构建进程。隐私政策通常是普通 HTML，若响应异常地返回几十 MB 文件，脚本不应该无限读入内存。这个上限同样属于团队规则，需要根据页面形态调整，不能包装成平台政策。

三、重定向必须逐跳观察，不能交给客户端悄悄完成

原生 fetch 默认自动跟随跳转，最终只能方便地拿到终点响应。对浏览器来说这是合理默认值，对审计脚本却会丢掉最重要的中间事实。PolicyProbe 采用 redirect: 'manual'，逐跳记录状态码和 Location，并给每一跳设置超时。

这段代码解决什么问题：显式采集重定向链，限制跳转次数、协议和最终主机，并在超时后释放请求。

// tools/policy-probe/fetchChain.ts
export interface Hop {
  url: string
  status: number
  location?: string
}

export async function fetchChain(entryUrl: string, maxRedirects: number):
  Promise<{ response: Response; hops: Hop[] }> {
  const hops: Hop[] = []
  let current = new URL(entryUrl)

  for (let index = 0; index <= maxRedirects; index++) {
    if (current.protocol !== 'https:') {
      throw new Error(`NON_HTTPS:${current.toString()}`)
    }

    const controller = new AbortController()
    const timer = setTimeout(() => controller.abort(), 5000)
    try {
      const response = await fetch(current, {
        redirect: 'manual',
        signal: controller.signal,
        headers: { 'user-agent': 'PolicyProbe/1.0' }
      })
      const location = response.headers.get('location') ?? undefined
      hops.push({ url: current.toString(), status: response.status, location })

      if (response.status < 300 || response.status >= 400) {
        return { response, hops }
      }
      if (!location || index === maxRedirects) {
        throw new Error(`REDIRECT_LIMIT:${hops.length}`)
      }
      current = new URL(location, current)
    } finally {
      clearTimeout(timer)
    }
  }
  throw new Error('UNREACHABLE')
}

循环上限写成 index <= maxRedirects，是因为“允许 3 次跳转”意味着最多会发出 4 次请求：一次入口请求加三次目标请求。这里最容易写出少一次或多一次的边界错误。报告里应同时输出跳转次数和请求次数，避免讨论时双方对数字含义不同。

状态在这一阶段从 QUEUED 变为 FETCHING。网络错误、证书错误、超时和跳转越界都应进入 BLOCKED，但错误码要分开，不能统一显示“访问失败”。如果构建环境必须通过代理，还要在文档中明确代理差异；本机成功不代表 CI 出口同样可达。

示例的第一次探测故意构造了四次跳转，因此被标记为 REDIRECT_LIMIT。修复路由后，入口只跳转一次到 /ledger/zh-cn，最终状态码为 200。这个前后差异会在诊断页里保留，而不是被第二次成功覆盖。

四、200 之后才是内容身份验证的开始

到达终点后，PolicyProbe 依次检查最终主机、状态码、内容类型、正文大小和身份标记。顺序很重要：如果主机已经越界，就不应继续把未知站点的大响应读进内存；如果内容类型不是 HTML，也没有必要执行文本标记匹配。

这段代码解决什么问题：把“能访问”拆成可解释的发现项，并对正文做有上限的读取和稳定摘要。

// tools/policy-probe/validate.ts
import { createHash } from 'node:crypto'
import type { PolicyProbeConfig } from './config'

export interface Finding {
  code: string
  message: string
}

export async function validateResponse(response: Response, cfg: PolicyProbeConfig) {
  const findings: Finding[] = []
  const finalUrl = new URL(response.url)
  const contentType = response.headers.get('content-type') ?? ''

  if (!cfg.allowedFinalHosts.includes(finalUrl.hostname)) {
    findings.push({ code: 'FINAL_HOST', message: finalUrl.hostname })
    return { findings, bodyBytes: 0, digest: '' }
  }
  if (response.status !== 200) {
    findings.push({ code: 'HTTP_STATUS', message: String(response.status) })
  }
  if (!contentType.toLowerCase().includes('text/html')) {
    findings.push({ code: 'CONTENT_TYPE', message: contentType })
  }

  const bytes = new Uint8Array(await response.arrayBuffer())
  if (bytes.byteLength > cfg.maxBodyBytes) {
    findings.push({ code: 'BODY_LIMIT', message: String(bytes.byteLength) })
  }
  const html = new TextDecoder('utf-8', { fatal: false }).decode(bytes)
  for (const marker of cfg.requiredMarkers) {
    if (!html.includes(marker)) {
      findings.push({ code: 'MARKER_MISSING', message: marker })
    }
  }
  const digest = createHash('sha256').update(bytes).digest('hex')
  return { findings, bodyBytes: bytes.byteLength, digest }
}

演示报告中的修复后数据为：最终地址 https://privacy.example.com/ledger/zh-cn，跳转 1/3，状态码 200，正文 184 KB，三个身份标记全部命中，耗时 413 ms，摘要显示为 9c17…4a2e。图片只展示缩略摘要，JSON 报告应保留完整 SHA-256。

上面的示例为便于阅读使用 arrayBuffer() 后再检查长度。生产脚本若面对不可信响应，应该先检查可信的 Content-Length，再通过流式读取在超过 512 KB 时主动终止；否则“上限”只限制验证结论，没有限制峰值内存。还要注意压缩响应：网络传输大小与解压后的正文大小并不是一回事，报告应写清采用哪一种口径。

摘要的用途是识别内容是否发生变化，不是证明法律文本正确。动态时间戳、A/B 注入或随机脚本可能让摘要每次不同。更成熟的实现可以先抽取正文容器、移除脚本和空白再摘要，但不要在规范化时误删关键条款。

完成核心脚本后，DevEco Studio 演示图把目录、校验代码、右侧 PrivacyAuditPage 和底部 HiLog 放在同一画面。它是按本文数据制作的说明图，不是一次真实 IDE 运行的证据。

五、把检查接进构建流程，但保留人工复核出口

门禁只有进入固定流程才有价值。示例在 Hvigor 构建前调用 Node.js 脚本，失败时返回非零退出码，同时写出 build/policy-probe/POLICY-LINK-0081.json。Hvigor 负责调度，网络与内容验证仍由普通 TypeScript 模块完成，这样可以单独测试，不把业务逻辑埋在构建 DSL 里。

这段代码解决什么问题：统一命令行退出语义、报告落盘和 HiLog 风格输出，让本地与 CI 使用同一入口。

// tools/policy-probe/main.ts
import { mkdir, writeFile } from 'node:fs/promises'
import { config } from './config'
import { fetchChain } from './fetchChain'
import { validateResponse } from './validate'

async function main(): Promise<void> {
  const startedAt = Date.now()
  console.info(`[PolicyProbe] task=${config.taskId} state=FETCHING`)
  const { response, hops } = await fetchChain(config.entryUrl, config.maxRedirects)
  console.info(`[PolicyProbe] task=${config.taskId} state=VALIDATING redirects=${hops.length - 1}`)
  const checked = await validateResponse(response, config)
  const state = checked.findings.length === 0 ? 'PASS' : 'BLOCKED'
  const report = {
    taskId: config.taskId,
    state,
    elapsedMs: Date.now() - startedAt,
    finalUrl: response.url,
    hops,
    ...checked
  }
  await mkdir('build/policy-probe', { recursive: true })
  await writeFile(`build/policy-probe/${config.taskId}.json`, JSON.stringify(report, null, 2))
  console.info(`[PolicyProbe] task=${config.taskId} state=${state} findings=${checked.findings.length}`)
  if (state !== 'PASS') process.exitCode = 2
}

main().catch((error: Error) => {
  console.error(`[PolicyProbe] task=${config.taskId} state=BLOCKED error=${error.message}`)
  process.exitCode = 3
})

退出码 2 表示“请求成功但规则不满足”，退出码 3 表示“探测过程异常”。区分二者后，CI 可以把前者交给内容或发布负责人，把后者交给基础设施负责人。无论失败还是成功都应保留报告；只在成功时落盘，会抹掉最需要排查的现场。

这里没有示范自动修改 AppGallery Connect 的资料。发布接口与权限角色需要按官方文档和团队授权另行设计，预检脚本也不应持有超出需要的发布凭据。更安全的边界是：脚本产生证据和阻断，授权人员在控制台或受控流水线中完成提交。

六、诊断页要让人看懂“阻断在哪里”

命令行适合 CI，但发布负责人通常更需要一眼看懂的结果。PrivacyAuditPage 读取同一份 JSON 报告，不再自行请求网络。这样界面显示与构建结论来自同一快照，不会出现“CI 失败、手机页面重新请求后又成功”的时间差。

首屏突出任务编号 POLICY-LINK-0081、当前状态 RECHECKED → PASS、最终状态码 200、跳转 1/3、身份标记 3/3。成功不是用一大片绿色掩盖细节，下面仍显示最终地址、正文 184 KB 和耗时 413 ms，方便判断是否接近阈值。

详情页则承担解释职责：它列出第一次 BLOCKED 的两个发现项——REDIRECT_LIMIT 与 APP_NAME_MISMATCH，再展示修复后的单次跳转链。红色箭头只指向状态转换和摘要，不装饰所有字段。两张手机图都使用 15:18、5G、Wi‑Fi、信号和 82% 电量，保证同一次演示的时间语义一致。

状态恢复也要有规则。只有配置、入口地址或页面摘要发生变化时，才允许从 BLOCKED 进入 RECHECKED；网络偶发失败后的无条件自动重试不应该直接覆盖阻断。建议保留 attempt 字段和上一轮报告路径，让每次复查都能追溯。

如果页面需要登录、地域限制或验证码，普通构建机可能无法稳定检查。这时不要加入绕过逻辑。更合适的处理是把限制作为明确发现项，调整公开访问策略，或为合规页面提供稳定的匿名入口。发布所需页面如果只能在特定会话中打开，本身就值得重新审视。

七、门禁的边界与上线前核对表

PolicyProbe 解决的是工程一致性，不是法律判断。它能发现 URL 不可达、跳转链异常、最终主机偏移、响应类型错误、正文过大和身份标记缺失；它不能判断条款是否覆盖全部个人信息处理场景，也不能证明 SDK 实际行为与声明一致。

上线前还应检查四类边界。

其一是多语言页面。中文入口跳到英文默认页时，状态码和域名都可能正确，却不满足目标市场。可以把语言标记和 lang 属性纳入清单，但要避免只凭 URL 路径推断语言。

其二是缓存。CDN 可能让不同地区拿到不同版本。CI 的一次探测只能代表当时出口，重要发布可从多个受控节点检查，并在报告中记录响应头与时间，而不是宣称“全球可达”。

其三是内容安全。报告不应保存完整隐私正文或 Cookie，只保留必要元数据、发现项与摘要。日志里的 URL 也要过滤临时签名参数，避免预检本身制造泄露。

其四是规则版本。门禁阈值变化后，旧报告不能继续解释为新规则下的通过。建议在报告加入 ruleVersion，例如 policy-probe/1.0，并把配置与报告一起归档。

本例最终的发布判断很克制：POLICY-LINK-0081 在演示规则下从 BLOCKED 经修复进入 RECHECKED → PASS，发现项从 2 变为 0。这个 PASS 只表示示例 URL 在该次快照中满足可达性和内容身份门禁。真正提交前，仍需由发布、隐私和产品负责人检查页面文本、应用行为与控制台资料是否一致。

八、把失败分级，否则门禁会很快失去信用

发布门禁上线后，最容易出现的反作用不是误判，而是所有失败都被标成同一种紧急程度。一次 DNS 抖动、一次内容身份不匹配和一次最终域名越界，对应的负责人、风险和处理时限完全不同。如果流水线只给出“隐私政策检查失败”，团队很快会养成点击重试的习惯，真正的内容错误也会被当作网络噪声。

可以把发现项分成三组。第一组是确定性内容错误，例如应用名称、开发者名称或生效日期缺失。这类错误重试不会自行恢复，应直接阻断并要求内容负责人确认。第二组是确定性路由错误，例如非 HTTPS、最终主机不在白名单、跳转超过团队阈值。这通常由站点或发布工程负责人处理，也不适合自动放行。第三组是暂时性基础设施错误，例如解析超时、连接重置或服务端五百错误。它可以在有限次数内退避重试，但每次尝试都要保留独立记录。

重试策略不能写成无限循环。示例可以设置两次补充尝试，间隔分别为两秒和六秒；如果仍失败，就输出 NETWORK_UNSTABLE 并阻断。这里的次数和间隔是工程参数，不是平台要求。关键是让报告清楚区分“第几次请求成功”和“规则检查是否通过”。如果第二次请求拿到 200，但内容身份仍不匹配，最终状态依然应该是 BLOCKED。

内容负责人修复页面后，也不应该直接编辑旧报告中的结论。正确做法是创建新的 attemptId，继承任务编号 POLICY-LINK-0081，重新记录时间、跳转链、正文摘要和发现项。这样才能解释为什么同一个任务先后出现两个不同结论。诊断页展示的 RECHECKED → PASS 本质上是两个不可变快照之间的关系，而不是把失败记录涂成绿色。

九、测试用例应覆盖“看似成功”的错误页面

这类工具如果只用真实网站测试，很难稳定覆盖边界。更合适的方式是在测试进程中启动一个受控 HTTP 服务，分别返回单次跳转、循环跳转、跨域跳转、错误内容类型、超大正文、缺失标记和正常页面。测试断言关注发现码、跳转链和退出码，不依赖外部网络。

其中最重要的用例是“200 错误页”。测试服务返回状态 200 和 text/html，页面标题写“系统维护中”，但不包含“星账本”、开发者名称和生效日期。预期结果必须是三个 MARKER_MISSING，而不是 PASS。第二个关键用例是“入口合法、终点越界”：入口位于白名单域名，随后跳转到未授权主机，检查器必须在读取正文前停止。

字符编码也值得单独测试。服务声明 UTF-8，正文却使用其他编码时，简单的 TextDecoder('utf-8') 可能产生替换字符并导致标记缺失。实际项目可以根据可信的响应头选择解码器，但不要盲目信任任意字符集名称。对于团队完全控制的隐私站点，统一 UTF-8 通常比在预检脚本中兼容所有历史编码更可维护。

还应构造内容长度声明与实际正文不一致的响应。Content-Length 只能作为提前拒绝的线索，最终仍需按实际读取字节计数。若服务端使用压缩或分块传输，报告要明确记录“传输字节”与“解压正文”哪个值触发上限。只有口径固定，184 KB 这样的数字才有比较意义。

十、把发布资料视为同一个版本化对象

隐私政策 URL 往往由运营表格维护，应用名称来自产品配置，开发者名称来自账号资料，构建脚本则来自代码仓库。四份数据各自正确，组合起来仍可能错。更稳妥的做法是为一次发布建立版本化清单，至少包含应用版本、包标识、政策入口、期望身份标记、规则版本和生成时间。

PolicyProbe 读取这份清单，构建产物也记录清单摘要。发布负责人看到 PASS 时，应该能够反查它对应的是哪个应用版本和哪份隐私页面，而不是只有一个孤立的绿色状态。如果应用改名但政策页面尚未更新，清单评审就能提前暴露差异；如果页面摘要变化而应用版本未变，也能触发内容复核。

清单不应包含密钥、登录 Cookie 或临时签名。需要鉴权才能访问的政策页面不适合作为公开发布资料，脚本也不应为了“检查成功”而携带私人会话。所有网络请求应限制为 GET，并禁止把站点返回的脚本当作程序执行。我们只解析文本和响应元数据，不启动无头浏览器运行页面代码，从而缩小检查器自身的攻击面。

最终交付报告可以附带一个简短人工确认区：页面能否在未登录环境打开、正文是否与当前版本功能相符、第三方 SDK 清单是否同步、用户权利入口是否可用。脚本负责提供稳定事实，人负责作出超出关键词匹配能力的判断。这样的分界比追求一个“全自动合规分数”更诚实，也更容易长期维护。

十一、参考资料

  • 华为开发者联盟：AppGallery Connect 应用审核与发布相关指南，https://developer.huawei.com/consumer/cn/doc/app/agc-help-releaseharmonyapp-0000001914554900
  • 华为开发者联盟：隐私政策配置与合规说明，https://developer.huawei.com/consumer/cn/doc/app/agc-help-configureprivacypolicy-0000001937811169
  • 华为开发者联盟：HarmonyOS 应用隐私政策协议更新接口，https://developer.huawei.com/consumer/cn/doc/AppGallery-connect-Guides/agcapi-app-agreement-update-0000001978234753
  • Node.js 文档：Fetch API 与 AbortController，https://nodejs.org/api/globals.html#fetch
# harmonyos # node.js # 华为
Logo
人工智能6S服务平台

作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。

更多推荐

cover

HarmonyOS 7 Spatial Recon Kit 开发实录 02：相机内参与位姿校验驱动的多角度帧采集【鸿蒙心迹】

avatar 人工智能6S服务平台
cover

HarmonyOS 7 Spatial Recon Kit 开发实录 05：PLY 与 MP4 结果写出、任务目录与完整性校验【鸿蒙心迹】

avatar 人工智能6S服务平台
cover

HarmonyOS 7 Spatial Recon Kit 开发实录 01：支持检测、Session 创建与首条有效重建链路【鸿蒙心迹】

avatar 人工智能6S服务平台