证书字段的文字边缘出现差异时，最容易发生的误判是：把两张看起来不同的截图直接归因于抗锯齿。姓名可能变长，日期可能被修改，背景可能从图片换成渐变，显示区域也可能已经变化。它们都会改变画面，却不是抗锯齿开关本身造成的结果。

要处理这类复核，不需要把问题写成“哪张更清楚”，而要把证据分成三个层次：比较基线是否一致、设置请求是否被页面接受、设备上的实际画面是否可观察。当前项目能完整保留前两层的一部分事实；第三层必须依赖同环境取图和人工复核。以下内容据此展开。

一、先把“看起来不同”拆成三层事实

1. 比较基线：两张图是否仍在看同一件事

基线层回答的是“这两次绘制是否可比”。证书中的姓名、日期、背景和画布显示区域都属于这一层。它们不一定是质量问题，却会改变文字轮廓、对比度或排版比例。

当前项目对姓名有一条明确规则：超过 12 个字符时，使用较小的字号范围；短姓名使用另一组字号。这个规则的目的，是避免长姓名挤出证书版式。它同时意味着，长短姓名不能作为同一轮抗锯齿对照的前后样本。背景和显示区域也应按同样的原则处理：背景改变了文字周边对比度，显示区域参与字号、边框和印章的比例计算。

基线项	为什么必须固定	变化后的处理
获证人姓名	字符数量会触发不同的字号计算。	建立新的比较轮次。
获得时间	字段内容变化会改变页面文字分布。	建立新的比较轮次。
背景状态	图片背景和渐变背景的对比度不同。	建立新的比较轮次。
显示区域	宽高会影响文字和图形的比例。	记录变化后重新取基线图。

基线没有固定时，后续截图最多只能说明“画面变了”，不能说明“抗锯齿造成了变化”。

2. 设置请求：页面到底做了哪一次操作

请求层回答的是“本轮有没有向 Canvas 提交新的抗锯齿状态”。这里关注的不是肉眼观感，而是开关的原值、目标值、是否抛出异常，以及失败时是否恢复。

当前项目将状态保存在 antialiasEnabled 中。点击后，页面先保存原值，反转布尔状态，调用设置处理；设置失败时再恢复原值。这一层可由页面状态文字和操作日志佐证，不需要从截图边缘反推。

3. 设备观察：画面是否真的呈现出可复核差异

观察层才涉及文字边缘。它需要在相同设备、相同显示条件下取得两张独立画面，再由人工查看。当前项目不会保存切换前后的双份画面；切换后屏幕只保留当前重绘结果。因此，页面状态不能代替前后对照材料，必须用两次取图和同一轮操作日志补齐。

这三层的顺序不能颠倒。先有可比较的基线，才有意义发起设置请求；先确认请求结果，才值得进入设备侧观察。

二、当前项目怎样生成一张可供复核的证书

1. 画布就绪和尺寸确认是绘制的前提

证书重绘并不会在任意时刻直接开始。当前项目会先确认画布已经就绪，且当前显示区域的宽高有效；条件不满足时，本轮不会进入绘制。显示区域发生变化后，页面会更新当前尺寸并重新执行绘制。

这解释了为什么“同一姓名、同一开关”仍可能得到不同画面：显示区域一旦变化，后续所有与宽高相关的比例计算都可能变化。验收记录不必展示实现细节，但必须在两次取图时保留相同的显示条件，或明确标记尺寸已变。

2. 字段校验和背景选择发生在文字绘制之前

开始绘制前，页面会先检查姓名是否为空。为空时，页面提示“请填写获证人姓名”，不会把空字段当作一张有效证书继续绘制。姓名有效后，页面才处理抗锯齿请求、清空画布、填充当前背景并绘制各字段。

背景状态也进入同一条绘制流程：当前项目在内置图片背景和 Canvas 渐变之间切换。二者都能承载证书文字，但不应混入同一组边缘观察。对验收来说，它们是基线条件，不是本篇要比较的技术变量。

3. 姓名字号不是固定值

const nameSize: number = name.length > 12
  ? Math.max(23, Math.min(width * 0.04, 34))
  : Math.max(28, Math.min(width * 0.052, 44));

this.context.font = `600 ${nameSize}px serif`;
this.context.fillText(name, width / 2, height * 0.62);

这段代码能够证明，姓名长度和当前宽度共同参与字号计算，随后才绘制姓名。它不能证明两次画面的字号相同，因为代码并不保存上一轮输入和尺寸。正因如此，姓名、显示区域都必须进入比较基线，而不是在看到差异后才回头猜测。

三、开关动作应当怎样解释

1. 先请求，再决定页面显示什么状态

抗锯齿开关的关键不在按钮颜色，而在它能否把目标状态提交给 Canvas。当前项目的处理如下：

private applyAntialias(): boolean {
  try {
    this.context.antialias = this.antialiasEnabled;
    return true;
  } catch (_error) {
    this.antialiasStatus = '当前运行环境不支持动态抗锯齿';
    return false;
  }
}

private toggleAntialias(): void {
  const previous: boolean = this.antialiasEnabled;
  this.antialiasEnabled = !previous;
  if (this.applyAntialias()) {
    this.antialiasStatus = `已从${previous ? '开启' : '关闭'}切换为${this.antialiasEnabled ? '开启' : '关闭'}`;
  } else {
    this.antialiasEnabled = previous;
    this.applyAntialias();
  }
  this.renderCertificate();
}

从这段逻辑可以得到三条明确结论：

1. 设置未报异常时，页面会记录“已从开启切换为关闭”或相反的状态，说明本轮已按目标值提交设置请求。
2. 设置发生异常时，页面会记录“不支持动态抗锯齿”，并恢复开关原值；该结果应保留为环境异常，不应被下一次点击覆盖。
3. 无论请求成功还是恢复原值，页面都会触发一次证书重绘。切换后的屏幕不是旧画面残留。

代码不能证明的是设备侧画面差异。赋值未抛异常，只能说明请求层没有报告错误；它不包含像素比对、字体栅格报告或人工可读性结论。

2. 重绘链路为什么还会再次请求当前状态

证书重绘在清空画布和绘制文字前，会再次请求当前抗锯齿状态。这个安排使“开关刚刚改变的值”和“本轮文字绘制所用的值”处于同一条流程内：先处理当前状态，再清空画布，再写入文字。

this.applyAntialias();
this.context.clearRect(0, 0, width, height);
// 处理背景、边框和证书字段后，再绘制姓名与日期

这段代码能够证明当前绘制先请求抗锯齿状态，随后才清空并重新输出内容。它不能说明第一次开关请求一定改变了肉眼观感，也不能说明不同设备会以同样方式实现文字栅格化。

四、一次有效比较应按什么顺序完成

下面的操作不是为了增加步骤，而是分别补足前文的三层证据。

步骤一：建立基线

填写或确认姓名和日期，确定背景状态，等待画布稳定后记录当前显示条件。此时不要切换抗锯齿。保存第一张画面，并在操作日志中写入当前开关状态。

若姓名为空，或显示区域仍在变化，本轮不进入下一步。前者没有有效文字对象，后者没有固定的比较尺寸。

步骤二：只执行一次设置请求

保持字段和背景不变，点击一次抗锯齿开关。读取页面状态：若显示切换方向，继续取第二张图；若显示不支持，记录异常并结束本轮。不要通过连续点击来“试到成功”，否则操作轮次和状态来源都会混乱。

步骤三：在同一环境下补第二张图

第二张图应与第一张图使用同一设备、同一显示条件和同一组字段。当前项目不会替你保留第一张，因此两张图和操作日志必须用同一轮次标识关联。页面显示“证书已生成”只能作为本地重绘完成的佐证，不能替代第一张基线图。

步骤四：按证据强度写结论

已取得的事实	允许写入的结论	不应写入的结论
字段、背景和尺寸保持一致	本轮具备比较前提。	文字质量已通过。
页面提示切换成功并完成重绘	已完成一次本地设置请求和重绘。	所有设备已生效。
两张图来自同一设备和同一轮次	可进入人工边缘观察。	平台对文字质量作出保证。
页面提示不支持	当前环境未完成该设置请求。	开关已关闭但效果不明显。

五、交接资料需要留下哪些东西

文章最后回到素材验收本身。一张截图只能保留一个时刻的视觉状态，不能保留它为什么可以参与比较。交接时至少需要把基线、请求和观察三类材料对应起来：

材料	对应层次	用途
第一张与第二张页面图	设备观察	供同环境下的人工边缘复核。
姓名、日期、背景和显示条件	比较基线	证明两张图是否可并列。
开关前后状态与异常提示	设置请求	说明本轮实际提交了什么，是否被页面拒绝。
布局 JSON 与操作日志	三层关联	还原页面状态、操作顺序和取图轮次。

出现以下任一情况，都应标记为“重新建立基线”或“待环境复核”：姓名、日期、背景、显示区域发生变化；姓名为空；页面提示不支持动态抗锯齿；两张图不在同一设备或同一轮次。这个出口比强行给出通过或不通过更有用，因为它直接告诉下一位复核人员缺的是哪一层证据。

六、适用范围

本文处理的是运行时文本抗锯齿开关在证书字段端侧预览中的比较条件。它可以帮助复核人员判断：当前项目是否在固定基线下提交了设置请求，页面是否报告异常，以及两次画面是否具备进入人工观察的条件。

它不回答“哪种状态一定更清楚”“所有设备是否一致”“证书是否有效”或“资料是否已归档”。前两项需要设备和人工观察证据，后两项需要独立的业务系统记录。将这些结论分层，才能避免让一张端侧预览图承担超出它能力范围的证明。

必要条件｜从SDK到设备的依赖链路

本文技术点的运行链路必须按以下顺序成立：

1. SDK/API：工程使用 HarmonyOS 6.1.1（API 24），DevEco Studio 和 Hvigor 能完成 entry 模块构建。

   

2. Kit：源码实际引入本文所需 Kit，例如 @kit.CameraKit、@kit.MapKit、@kit.NotificationKit、@kit.SpeechKit 或 @kit.VisionKit。

3. 模块/页面：页面路由写入 main_pages.json，模块保持 Stage 配置，相关权限写入 entry/src/main/module.json5。

4. 权限：动态能力调用前完成 CAMERA、MICROPHONE 或其他系统授权；网络页面确认 INTERNET 已声明。

5. 系统能力/硬件：设备满足本文 API 和能力要求。相机、麦克风、地图、CardRecognition 等能力缺失时必须进入降级分支。
   

MapKit文章在上述链路后增加服务配置：在 AppGallery Connect 创建或选择项目，绑定与工程一致的包名和签名证书，进入服务管理开通 MapKit，并按控制台要求完成应用服务凭据/授权配置；不要在文章或源码中公开 App ID、Client ID、API 密钥或私钥。完成后再验证地图初始化、搜索或事件回调。