一、问题与目标

纹渊的创作流程同时涉及 Canvas 绘制、3D 预览、AI 生图、文件选择、图片导出和跨端迁移。如果工程基线没有先收住，后面任何一个页面问题都可能被误判成 UI bug：模拟器安装失败可能来自签名包，接口不可用可能来自权限，平板布局异常可能来自设备类型声明，而不是页面本身。

API 26 基线的价值在于把这些前置条件固定下来。编译 SDK、兼容版本、设备类型、网络权限和签名输出先形成一张清单，页面开发时才不会一边改业务一边排查环境。对于纹渊这种同时跑图像和模型预览的应用，基线不是“构建配置”，而是后续功能能否稳定验收的入口。

二、实现思路

工程层可以分成三条线检查：第一条是构建线，确认编译版本、兼容版本和产物路径稳定；第二条是运行线，确认手机、平板和 2in1 都在声明范围内；第三条是能力线，确认网络、文件、图片和模型资源都能被运行时正确访问。

这些配置不应该等到页面写完才补。比如 AI 生图需要网络权限，模型预览需要资源加载路径，跨端迁移需要设备能力判断。把这些能力前置成基线后，页面只需要关心功能状态，环境问题会更早暴露。

基线项	处理方式
编译版本	统一到 HarmonyOS 7 / API 26，减少新 API 与旧设备能力错配
兼容版本	保留低版本运行边界，避免只在开发机上可用
设备类型	覆盖 phone、tablet、2in1，方便后续断点布局和窗口适配
签名产物	以可安装包为验收对象，避免只通过预览器判断功能

三、关键实现

这段配置检查的重点不是把构建文件搬进正文，而是把版本、设备和权限收敛成一个可校验对象。构建前先检查基线，能提前发现设备类型漏配、SDK 版本不一致、权限声明缺失等问题。

const buildTarget: BuildTarget = {
  compileSdk: 26,
  compatibleSdk: 23,
  deviceTypes: ['phone', 'tablet', '2in1'],
  permissions: ['INTERNET'],
  releaseMode: 'signed'
}

function verifyTarget(target: BuildTarget): string[] {
  const issues: string[] = []
  if (target.compileSdk < 26) {
    issues.push('compile sdk should follow the HarmonyOS 7 baseline')
  }
  if (!target.deviceTypes.includes('phone')) {
    issues.push('phone must stay in the supported device list')
  }
  return issues
}

这里把编译版本、兼容版本、设备类型和权限放在同一个对象里，是为了让构建检查具备可读性。页面出现网络请求失败时，先能判断是不是权限未声明；平板页面没有按预期进入宽屏布局时，也能先回到设备类型声明上排查。

基线检查不需要复杂，关键是稳定。只要每次构建前都能得到同一组结论，后续排查 Canvas、3D、AI 请求或跨端迁移时，就不用把环境变量和业务状态混在一起看。

四、失败场景与取舍

最常见的失败并不在代码片段里，而在基线被默认忽略。比如只声明 phone，平板上仍能运行但布局断点无法按预期触发；只在调试包里验证网络，签名包安装后才发现权限或配置不完整；只看预览器效果，不看真实安装包，就容易漏掉资源路径和沙箱访问问题。

处理方式是把“能构建”“能安装”“能打开首页”“能走到创作页”拆成四个验收点。任何一个点失败，都先停在工程层排查，不急着修改页面逻辑。这样可以避免把签名、权限、资源和 UI 状态混在同一个问题里。

五、验证步骤

1. 打开创作入口，确认标题、主要卡片、底部操作区和预览区域显示正常。
2. 走一遍主流程，观察加载态、成功态和下一步按钮是否同步变化。
3. 人为制造空输入、重复点击或不可用条件，确认页面给出可理解的提示。
4. 返回上一页再进入，确认选中态、预览结果和关键状态没有漂移。
5. 在较窄窗口和较宽窗口各看一遍，确认文字、卡片和按钮没有重叠。

六、总结

API 26 工程基线解决的是纹渊后续功能的共同地基。构建版本、设备类型、权限和签名产物先稳定下来，Canvas 绘制、3D 预览和 AI 请求的验证才有可靠上下文。