Carousel Pattern 详解：构建无障碍轮播组件

轮播（Carousel）是一种按顺序展示一组内容项（称为幻灯片）的组件。本文基于 W3C WAI-ARIA Carousel Pattern 规范，详解如何构建无障碍的轮播组件。

一、Carousel 的定义与核心概念

1.1 什么是 Carousel

Carousel（也称为幻灯片或图片轮播器）具有以下特征：

• 展示一组称为**幻灯片（Slide）**的内容项
• 通常一次显示一个幻灯片，通过控制按钮切换
• 可以自动轮播，也可以手动控制
• 幻灯片可以包含任何类型的内容，图片轮播最为常见

1.2 核心术语

术语	说明
Slide	轮播中的单个内容容器
Rotation Control	停止/启动自动轮播的交互控件
Next Slide Control	显示下一张幻灯片的控件（通常为箭头样式）
Previous Slide Control	显示上一张幻灯片的控件（通常为箭头样式）
Slide Picker Controls	选择特定幻灯片的控件组（通常为圆点样式）

┌─────────────────────────────────────────────────────────────┐
│  Carousel (role="region" + aria-roledescription)            │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │                                                     │    │
│  │              ┌─────────────────┐                    │    │
│  │              │    Slide 1      │                    │    │
│  │              │  ┌───────────┐  │                    │    │
│  │              │  │           │  │                    │    │
│  │              │  │  Image /  │  │  <-- Current       │    │
│  │              │  │  Content  │  │      Slide         │    │
│  │              │  │           │  │                    │    │
│  │              │  └───────────┘  │                    │    │
│  │              └─────────────────┘                    │    │
│  │                                                     │    │
│  │  ┌─────────────────────────────────────────────┐    │    │
│  │  │  Slide 2 (hidden)    │   Slide 3 (hidden)   │    │    │
│  │  └─────────────────────────────────────────────┘    │    │
│  │                                                     │    │
│  └─────────────────────────────────────────────────────┘    │
│                                                             │
│     <-- Prev        o O O        Next -->                   │
│           (Slide Picker / Dots Navigation)                  │
│                                                             │
│                    [ Pause/Play ]                           │
└─────────────────────────────────────────────────────────────┘

1.3 无障碍挑战

轮播组件如果没有正确实现，会对无障碍体验造成严重影响：

• 屏幕阅读器用户困惑：如果不可见的幻灯片没有被正确隐藏，用户可能在不知情的情况下从幻灯片 1 跳转到幻灯片 2 的内容
• 自动轮播干扰：自动轮播可能打断屏幕阅读器用户的浏览流程
• 键盘导航困难：如果轮播没有正确处理焦点管理，键盘用户可能无法有效控制轮播

二、WAI-ARIA 角色与属性

2.1 基本角色

轮播区域使用 role="region" 标记为地标区域，并通过 aria-roledescription="carousel" 提供额外的角色描述：

<section
  role="region"
  aria-roledescription="carousel"
  aria-label="产品展示">
  <!-- 轮播内容 -->
</section>

2.2 幻灯片属性

每个幻灯片具有以下属性：

• role="group"：将幻灯片标记为一个组
• aria-roledescription="slide"：提供幻灯片的角色描述
• aria-label 或 aria-labelledby：提供幻灯片的可访问标签

<div
  role="group"
  aria-roledescription="slide"
  aria-label="第 1 张，共 3 张">
  <!-- 幻灯片内容 -->
</div>

2.3 幻灯片可见性

使用 aria-hidden 控制幻灯片的可见性：

• aria-hidden="true"：幻灯片不可见（不在视口内）
• aria-hidden="false"：幻灯片可见（当前显示的幻灯片）

<!-- 当前显示的幻灯片 -->
<div
  role="group"
  aria-roledescription="slide"
  aria-label="第 1 张，共 3 张"
  aria-hidden="false">
  <img
    src="slide1.jpg"
    alt="产品图片 1" />
</div>

<!-- 隐藏的幻灯片 -->
<div
  role="group"
  aria-roledescription="slide"
  aria-label="第 2 张，共 3 张"
  aria-hidden="true">
  <img
    src="slide2.jpg"
    alt="产品图片 2" />
</div>

2.4 控制按钮属性

上一张/下一张按钮

使用 aria-controls 属性指向被控制的幻灯片容器 ID，让辅助技术用户了解按钮会影响哪个区域的内容：

<button
  aria-label="上一张"
  aria-controls="carousel-slides">
  ←
</button>
<button
  aria-label="下一张"
  aria-controls="carousel-slides">
  →
</button>

轮播控制按钮（停止/启动）

使用 aria-pressed 表示按钮的按下状态，false 表示轮播正在运行，点击后会停止：

<button
  aria-label="停止轮播"
  aria-pressed="false"
  aria-controls="carousel-slides">
  ⏸
</button>

幻灯片选择器（圆点导航）

幻灯片选择器使用 role="tab" 模式，每个圆点按钮都是一个 tab，通过 aria-selected 表示当前选中的幻灯片：

<div
  role="tablist"
  aria-label="幻灯片选择">
  <button
    role="tab"
    aria-label="第 1 张"
    aria-selected="true"
    aria-controls="slide-1"></button>
  <button
    role="tab"
    aria-label="第 2 张"
    aria-selected="false"
    aria-controls="slide-2"></button>
  <button
    role="tab"
    aria-label="第 3 张"
    aria-selected="false"
    aria-controls="slide-3"></button>
</div>

三、键盘交互规范

3.1 基本键盘交互

按键	功能
Tab / Shift + Tab	在轮播的交互元素之间移动焦点
Space / Enter	激活按钮（上一张、下一张、停止/启动）
方向键（可选）	如果幻灯片选择器使用 Tab 模式，可用方向键切换幻灯片

3.2 自动轮播的键盘行为

• 当轮播中的任何元素获得键盘焦点时，自动轮播必须停止
• 轮播不会自动恢复，除非用户明确激活旋转控制

3.3 Tab 顺序

• 旋转控制按钮（如果存在）必须是轮播内部 Tab 顺序中的第一个元素
• 这确保辅助技术用户可以轻松找到控制按钮

四、鼠标交互规范

4.1 悬停行为

• 当鼠标悬停在轮播上时，自动轮播必须停止
• 鼠标移出后，可以恢复自动轮播（根据设计决定）

4.2 点击行为

• 点击上一张/下一张按钮切换幻灯片
• 点击幻灯片选择器跳转到特定幻灯片
• 点击旋转控制按钮停止/启动自动轮播

五、实现方式

5.1 基础轮播结构

<section
  class="carousel"
  aria-roledescription="carousel"
  aria-label="产品展示">
  <!-- 旋转控制按钮 -->
  <button
    class="rotation-control"
    aria-label="停止轮播"
    aria-pressed="false"
    aria-controls="carousel-slides">
    ⏸
  </button>

  <!-- 幻灯片容器 -->
  <div
    id="carousel-slides"
    class="carousel-slides">
    <div
      role="group"
      aria-roledescription="slide"
      aria-label="第 1 张，共 3 张"
      aria-hidden="false"
      class="slide active">
      <img
        src="slide1.jpg"
        alt="产品图片 1" />
      <div class="slide-content">
        <h2>产品标题 1</h2>
        <p>产品描述...</p>
        <a href="/product1">了解更多</a>
      </div>
    </div>

    <div
      role="group"
      aria-roledescription="slide"
      aria-label="第 2 张，共 3 张"
      aria-hidden="true"
      class="slide">
      <img
        src="slide2.jpg"
        alt="产品图片 2" />
      <div class="slide-content">
        <h2>产品标题 2</h2>
        <p>产品描述...</p>
        <a href="/product2">了解更多</a>
      </div>
    </div>

    <div
      role="group"
      aria-roledescription="slide"
      aria-label="第 3 张，共 3 张"
      aria-hidden="true"
      class="slide">
      <img
        src="slide3.jpg"
        alt="产品图片 3" />
      <div class="slide-content">
        <h2>产品标题 3</h2>
        <p>产品描述...</p>
        <a href="/product3">了解更多</a>
      </div>
    </div>
  </div>

  <!-- 导航按钮 -->
  <button
    class="prev-btn"
    aria-label="上一张"
    aria-controls="carousel-slides">
    ←
  </button>
  <button
    class="next-btn"
    aria-label="下一张"
    aria-controls="carousel-slides">
    →
  </button>

  <!-- 幻灯片选择器 -->
  <div
    class="slide-picker"
    role="tablist"
    aria-label="幻灯片选择">
    <button
      role="tab"
      aria-label="第 1 张"
      aria-selected="true"
      aria-controls="slide-1"></button>
    <button
      role="tab"
      aria-label="第 2 张"
      aria-selected="false"
      aria-controls="slide-2"></button>
    <button
      role="tab"
      aria-label="第 3 张"
      aria-selected="false"
      aria-controls="slide-3"></button>
  </div>
</section>

5.2 关键实现要点

幻灯片可见性管理：

• 当前显示的幻灯片：aria-hidden="false"
• 隐藏的幻灯片：aria-hidden="true"
• 使用 CSS 控制显示/隐藏（如 opacity、display 或 visibility）

自动轮播控制：

• 键盘焦点进入轮播区域时，必须停止自动轮播
• 鼠标悬停在轮播上时，必须停止自动轮播
• 提供停止/启动按钮，让用户控制自动轮播

幻灯片选择器状态：

• 当前幻灯片对应的按钮：aria-selected="true"
• 其他按钮：aria-selected="false"

六、常见应用场景

6.1 产品图片展示

<section
  aria-roledescription="carousel"
  aria-label="产品图片">
  <div
    role="group"
    aria-roledescription="slide"
    aria-label="第 1 张，共 4 张">
    <img
      src="product-1.jpg"
      alt="产品正面视图" />
  </div>
  <div
    role="group"
    aria-roledescription="slide"
    aria-label="第 2 张，共 4 张">
    <img
      src="product-2.jpg"
      alt="产品侧面视图" />
  </div>
  <div
    role="group"
    aria-roledescription="slide"
    aria-label="第 3 张，共 4 张">
    <img
      src="product-3.jpg"
      alt="产品背面视图" />
  </div>
  <div
    role="group"
    aria-roledescription="slide"
    aria-label="第 4 张，共 4 张">
    <img
      src="product-4.jpg"
      alt="产品细节视图" />
  </div>
</section>

6.2 testimonials/客户评价

<section
  aria-roledescription="carousel"
  aria-label="客户评价">
  <div
    role="group"
    aria-roledescription="slide"
    aria-label="第 1 张，共 3 张">
    <blockquote>
      <p>"这个产品改变了我的工作方式..."</p>
      <footer>— 张三，某公司员工</footer>
    </blockquote>
  </div>
  <div
    role="group"
    aria-roledescription="slide"
    aria-label="第 2 张，共 3 张">
    <blockquote>
      <p>"客服非常专业，响应迅速..."</p>
      <footer>— 李四，自由职业者</footer>
    </blockquote>
  </div>
</section>

6.3 新闻/公告轮播

<section
  aria-roledescription="carousel"
  aria-label="最新公告">
  <div
    role="group"
    aria-roledescription="slide"
    aria-label="第 1 张，共 3 张">
    <article>
      <h3>公司发布新产品</h3>
      <p>我们很高兴地宣布...</p>
      <a href="/news/1">阅读更多</a>
    </article>
  </div>
</section>

七、最佳实践

7.1 始终提供轮播控制

• 必须提供上一张/下一张按钮
• 如果启用自动轮播，必须提供停止/启动控制按钮
• 建议提供幻灯片选择器（圆点导航）

7.2 正确处理幻灯片可见性

• 使用 aria-hidden="true" 隐藏不可见的幻灯片
• 确保隐藏的幻灯片内容不会被屏幕阅读器读取
• 当前幻灯片使用 aria-hidden="false"

7.3 自动轮播的控制

• 自动轮播必须在以下情况下停止：
  • 键盘焦点进入轮播区域
  • 鼠标悬停在轮播上
  • 用户点击停止按钮
• 不要在用户未明确请求的情况下重新启动自动轮播

7.4 提供清晰的标签

• 为轮播区域提供描述性的 aria-label
• 为每个幻灯片提供包含位置信息的标签（如"第 1 张，共 3 张"）
• 为所有控制按钮提供清晰的 aria-label

7.5 避免使用轮播的情况

以下情况不建议使用轮播：

• 内容对用户都很重要，需要同时可见
• 用户需要比较不同幻灯片的内容
• 幻灯片内容包含重要的交互元素

在这些情况下，考虑使用静态列表或网格布局。

7.6 移动端触摸支持

移动端应支持触摸滑动切换幻灯片：

• 向左滑动 → 显示下一张
• 向右滑动 → 显示上一张
• 需要设置滑动阈值（如 50px），避免误触

八、总结

构建无障碍的 Carousel 组件需要特别关注：

1. 正确的 ARIA 标记：使用 role="region"、aria-roledescription、aria-hidden 等属性
2. 完整的键盘支持：确保所有功能都可以通过键盘访问
3. 自动轮播控制：提供停止/启动控制，并在焦点进入时自动停止
4. 清晰的标签：为轮播、幻灯片和控制按钮提供描述性标签
5. 幻灯片可见性管理：正确隐藏不可见的幻灯片，避免屏幕阅读器混淆

轮播组件虽然常见，但如果没有正确实现，会对无障碍体验造成严重影响。遵循 W3C Carousel Pattern 规范，我们能够创建既美观又包容的轮播组件，为所有用户提供良好的体验。

文章同步于 an-Onion 的 Github。码字不易，欢迎点赞。

很多开发者在把 Tauri 2 应用上架到 iOS（真机或模拟器）时，都会在文件保存这一步踩坑：明明代码代码在其他平台没问题，在 iOS 路径就返回 null，或者在「文件」App 里根本看不到自己的 App 文件夹。

下面我把最常见的几个坑总结成一份避坑科普文，帮你一次性避开这些“iOS 特色”问题。

坑 1：@tauri-apps/plugin-dialog 的 save() 在 iOS 上经常返回 null 或路径不可用

现象：
调用 const path = await save({...}) 后，一个 0KB 的文件写入成功，但是 path 返回是 null。

避坑方法：

• 不要过度依赖 dialog.save() 来实现“用户任意选择保存位置”。
• 优先使用 直接写入 App 的 Documents 目录（见坑 3）。
• capabilities 中确保开启 dialog:save 权限。

坑 2：文件明明写入了，但「文件」App 里完全看不到 “Mind Elixir” 文件夹

现象： 用了 BaseDirectory.Document 保存文件后，在「文件」App → 浏览 → On My iPhone 里找不到你的 App 文件夹。

原因： iOS 沙盒机制严格控制 App 的 Documents 目录是否对「文件」App 可见。Tauri 默认生成的 iOS 项目不会自动添加暴露文件夹的配置，就算你写再多文件，文件夹也不会出现。

避坑方法（最关键的一步）： 在 Info.plist 中添加以下两个 key（必须同时添加）：

<key>UIFileSharingEnabled</key>
<true/>
<key>LSSupportsOpeningDocumentsInPlace</key>
<true/>

位置：通常在 src-tauri/gen/apple/ios/App/App/Info.plist（或你的项目对应路径），加在 <dict> 标签内，</dict> 之前。

添加后必须重新构建并安装 App（cargo tauri ios build 或用 Xcode 编译），然后：

• 先执行一次写入操作（创建文件）。
• 完全退出「文件」App（上滑关闭），重新打开并下拉刷新「On My iPhone」。

此时你应该能看到和 App 同名的文件夹（显示名称来自 productName 或 Xcode Display Name）。

注意：这两个 key 只控制可见性，不影响代码读写。

坑 3：iOS 上最好的保存方式其实不是 dialog，而是直接用 Documents 目录

推荐做法：

import { writeTextFile, BaseDirectory } from '@tauri-apps/plugin-fs'

await writeTextFile('my-note.md', '你的内容...', {
  dir: BaseDirectory.Document
})

优点：

• 最稳定，几乎不会出现 0 字节文件的问题。
• 用户可以在「文件」App 里直接看到和管理文件（添加上面两个 plist key 后）。
• 无需处理复杂的 URI 和潜在的 fs bug。

如果你想让用户输入文件名，可以结合 prompt 或自定义输入框实现。

总结建议

在 Tauri 2 + iOS 开发中：

1. 优先使用 BaseDirectory.Document 直接保存（最稳）。
2. 必须在 Info.plist 添加 UIFileSharingEnabled 和 LSSupportsOpeningDocumentsInPlace。
3. 谨慎使用 dialog.save() + writeFile，因为移动端兼容性还有待完善（官方 issue 仍在跟进）。
4. 开发时多用控制台日志 + Safari/XCode 调试，遇到路径问题先检查 plist 和权限。

避开这几个坑后，你的 Mind Elixir（或其他 App）在 iOS 上的文件保存功能就会顺畅很多。iOS 的沙盒和文件系统规则和桌面差异很大，提前了解这些“Apple 特色”能省下大量调试时间。

（本文基于 Tauri 2 常见 issue 和实际开发经验总结，iOS 规则可能随系统版本微调，建议以 Apple 官方文档为准。）

上一篇已经拆解了大模型计费的底层逻辑：Token 是什么、官方如何收费，以及中转站倍率体系如何影响成本。但理解计费只是第一步，开发中更关键的问题是：知道它贵之后，如何把成本真正降下来。

需要先说明的是，本文中的案例将主要使用电商与客服场景来演示节省 Token 的方法。这样做是为了让成本结构更直观、优化路径更清晰；这些方法本身同样适用于多数具备多轮对话、工具调用、知识检索特征的 LLM 应用。

本文聚焦的问题是：在实际项目开发中，有哪些真正有效的策略可以减少 Token 消耗？ 文章不会停留在“少写点字”这类笼统建议上，而是从提示词工程、上下文管理、缓存策略、模型选择、架构设计五个维度，给出可直接落地的对比案例。

每个策略都会附上"优化前 vs 优化后"的对比，让你直观看到 Token 消耗的变化。

---

一、提示词精简：最直接的降本入口

提示词（System Prompt + User Prompt）是每次请求都会重复发送的内容。它的冗余程度，直接决定了你的输入 Token 基线。

1. 去除冗余描述和重复指令

很多开发者习惯在系统提示词里写得非常详细，甚至同一个意思用不同方式说了两三遍。模型并不需要这种"重复强调"。

❌ 优化前（约 180 Token）

你是一个非常专业的客服助手。你的任务是帮助用户解决问题。
你需要始终保持礼貌和专业。你回答问题时要简洁明了。
请不要回答与产品无关的问题。如果用户问了与产品无关的问题，
请礼貌地告诉用户你只能回答产品相关的问题。
你应该尽量用中文回答。回答时不要太长，保持简洁。
记住，你是客服助手，不是通用聊天机器人。

✅ 优化后（约 60 Token）

角色：产品客服助手
规则：
- 仅回答产品相关问题，其余礼貌拒绝
- 中文回答，简洁专业

节省效果：约 67% 的系统提示词 Token。 如果你的应用每天处理 1 万次请求，仅这一项优化每天就能减少约 120 万输入 Token。

许多提示词中的补充性表述并不会显著提升效果。除非场景确实需要多轮强调或额外约束，否则没有必要用面向人的沟通方式去“安抚”模型；从成本控制角度看，简洁明确往往更有效。

2. 使用结构化格式代替自然语言描述

模型对结构化指令的理解能力很强。与其用长段落描述规则，不如用 YAML、Markdown 列表或 JSON 格式。

❌ 优化前（约 250 Token）

当用户询问退款政策时，你需要告诉他们：如果商品在购买后7天内
且未拆封，可以全额退款。如果商品已拆封但在7天内，可以退款
但需要扣除15%的手续费。如果超过7天但在30天内，只能换货不
能退款。超过30天则不支持任何退款或换货服务。你需要根据用户
描述的情况判断属于哪种，然后给出对应的回答。

✅ 优化后（约 100 Token）

退款政策查找表：
| 条件 | 处理方式 |
|---|---|
| ≤7天 + 未拆封 | 全额退款 |
| ≤7天 + 已拆封 | 退款扣15%手续费 |
| 8-30天 | 仅换货 |
| >30天 | 不支持 |
根据用户情况匹配对应行回复。

节省效果：约 60% Token。 而且结构化格式还能提升模型的准确率，一举两得。

3. 用变量占位代替静态长文本

如果你的提示词里有大量静态内容（如产品说明、FAQ 列表），每次都原样发送会非常浪费。

❌ 优化前：把完整 FAQ 塞进每次请求（约 2000 Token）

System: 你是XX产品客服。以下是完整FAQ：
Q1: 如何注册？A: 打开官网点击注册...(200字)
Q2: 如何修改密码？A: 进入设置页面...(150字)
Q3: 支持哪些支付方式？A: 支持微信、支付宝...(180字)
...(共20条FAQ，总计约1800 Token)
请根据以上FAQ回答用户问题。

✅ 优化后：先分类再检索，只注入相关条目（约 300 Token）

System: 你是XX产品客服。根据以下相关FAQ回答：
{retrieved_faq}
如FAQ未覆盖，回复"我需要转接人工客服为您处理"。

其中 {retrieved_faq} 只包含与当前问题最相关的 1-3 条 FAQ。

节省效果：约 85% 的 FAQ 相关 Token。 这就是最基础的 RAG（检索增强生成）思路：不是把所有知识一次性塞给模型，而是只注入当前问题真正需要的内容。

---

二、上下文管理：控制多轮对话的隐形成本

上一篇已经提到，多轮对话中历史消息会在后续请求中被反复带入输入侧。这意味着对话越长，每一轮的输入 Token 成本就越高。

1. 滑动窗口：只保留最近 N 轮

最简单的策略是限制上下文长度，只把最近的几轮对话发给模型。

❌ 优化前：完整历史（第 10 轮时约 8000 Token 输入）

messages: [
  { role: "system", content: "..." },
  { role: "user", content: "第1轮问题" },
  { role: "assistant", content: "第1轮回答" },
  { role: "user", content: "第2轮问题" },
  { role: "assistant", content: "第2轮回答" },
  // ... 一直到第10轮
  { role: "user", content: "第10轮问题" }
]

✅ 优化后：滑动窗口保留最近 3 轮（约 2500 Token 输入）

messages: [
  { role: "system", content: "..." },
  { role: "user", content: "第8轮问题" },
  { role: "assistant", content: "第8轮回答" },
  { role: "user", content: "第9轮问题" },
  { role: "assistant", content: "第9轮回答" },
  { role: "user", content: "第10轮问题" }
]

节省效果：约 69% 的输入 Token。 对于大多数客服与问答场景，保留最近 3-5 轮通常已经足够。

2. 摘要压缩：用模型总结历史

如果业务需要更长的上下文记忆，可以用一次廉价的模型调用把历史压缩成摘要。

❌ 优化前：20 轮完整历史（约 15000 Token）

完整保留所有对话消息。

✅ 优化后：摘要 + 最近 3 轮（约 3500 Token）

messages: [
  { role: "system", content: "..." },
  { role: "system", content: "对话摘要：用户咨询了A产品的退款流程，
    已确认购买日期在7天内且未拆封，正在等待退款地址。" },
  { role: "user", content: "第18轮问题" },
  { role: "assistant", content: "第18轮回答" },
  { role: "user", content: "第19轮问题" },
  { role: "assistant", content: "第19轮回答" },
  { role: "user", content: "第20轮问题" }
]

节省效果：约 77%。 虽然生成摘要本身也会消耗 Token，但如果使用小模型（如 GPT-4o-mini）完成摘要，整体成本仍然远低于每一轮都携带完整历史。

3. 按需加载上下文而非全量注入

这是上下文管理中最容易被忽视的一点：不是所有上下文在每次请求时都需要。

❌ 优化前：每次请求都注入完整工具定义（约 3000 Token）

tools: [
  { name: "search_products", description: "...", parameters: {...} },
  { name: "check_order", description: "...", parameters: {...} },
  { name: "process_refund", description: "...", parameters: {...} },
  { name: "update_address", description: "...", parameters: {...} },
  { name: "send_email", description: "...", parameters: {...} },
  { name: "create_ticket", description: "...", parameters: {...} },
  // ... 共15个工具
]

✅ 优化后：根据意图分类，只注入相关工具（约 600 Token）

先用一次轻量分类（或规则匹配）判断用户意图，再只注入对应的工具子集：

// 用户意图: "退款"
tools: [
  { name: "check_order", description: "...", parameters: {...} },
  { name: "process_refund", description: "...", parameters: {...} }
]

节省效果：约 80%。 这一思路不只适用于工具定义，也适用于知识库片段、Schema 描述等所有“上下文素材”。

---

三、缓存策略：让重复内容只付一次全价

上一篇讲过，缓存命中的输入 Token 通常只按原价的 1/10 计费。所以，合理利用缓存机制是降本的重要手段。

1. 稳定前缀原则

缓存命中的前提是：请求的前缀部分和上次请求一致。所以，把不变的内容放前面，变化的内容放后面。

❌ 优化前：动态内容在前（缓存几乎无法命中）

messages: [
  { role: "user", content: "今天天气真好，我想问一下..." },
  { role: "system", content: "你是XX产品客服...（2000 Token 系统提示）" }
]

✅ 优化后：系统提示在前、动态内容在后（前缀可被缓存）

messages: [
  { role: "system", content: "你是XX产品客服...（2000 Token 系统提示）" },
  { role: "user", content: "今天天气真好，我想问一下..." }
]

节省效果： 假设系统提示 2000 Token，命中缓存后这部分从 2000 × Pin 降到 2000 × 0.1 × Pin，输入侧这部分节省 90%。

2. 批量请求共享前缀

如果你有一批类似任务（如批量翻译、批量分类），把它们组织成共享相同 system prompt 的连续请求，可以最大化缓存命中。

❌ 优化前：随机交替发送不同任务

请求1: [翻译系统提示] + 翻译任务A
请求2: [分类系统提示] + 分类任务B
请求3: [翻译系统提示] + 翻译任务C  ← 提示可能已被清出缓存
请求4: [分类系统提示] + 分类任务D  ← 提示可能已被清出缓存

✅ 优化后：同类任务集中发送

请求1: [翻译系统提示] + 翻译任务A
请求2: [翻译系统提示] + 翻译任务C  ← 缓存命中
请求3: [翻译系统提示] + 翻译任务E  ← 缓存命中
...
请求N: [分类系统提示] + 分类任务B
请求N+1: [分类系统提示] + 分类任务D  ← 缓存命中

节省效果： 如果批量处理 100 个翻译任务，系统提示为 1500 Token，那么第一个请求按原价计费，后 99 个请求命中缓存后按缓存价计费，可节省约 89% 的系统提示输入成本。

---

四、模型选择：不是所有任务都需要最强模型

这可能是最容易被忽视、但收益最显著的策略之一：不同任务使用不同模型。

1. 任务分级路由

❌ 优化前：所有任务统一用 Claude 3.5 Sonnet

意图识别 → Claude 3.5 Sonnet（$3/1M 输入，$15/1M 输出）
简单问答 → Claude 3.5 Sonnet
复杂推理 → Claude 3.5 Sonnet
文本分类 → Claude 3.5 Sonnet

✅ 优化后：按任务复杂度路由

意图识别 → GPT-4o-mini（$0.15/1M 输入，$0.6/1M 输出）
简单问答 → GPT-4o-mini
复杂推理 → Claude 3.5 Sonnet
文本分类 → GPT-4o-mini

假设流量分布是：60% 简单任务 + 25% 中等任务 + 15% 复杂任务：

任务类型	流量占比	优化前单价（输出）	优化后单价（输出）
简单任务	60%	$15/1M	$0.6/1M
中等任务	25%	$15/1M	$0.6/1M
复杂任务	15%	$15/1M	$15/1M

加权平均输出单价：从 $15/1M 降到约$15/1M降到约2.76/1M，节省约 82%。

2. Thinking 模式的精准使用

上一篇说过，thinking 模式会额外产生大量推理 Token。所以它只应该在真正需要复杂推理时开启。

❌ 优化前：所有请求都开 thinking

一个简单的格式转换任务：

输入 Token: 500
可见输出 Token: 200
thinking Token: 2000  ← 模型"想"了很多但完全没必要
总输出计费: 2200 Token

✅ 优化后：仅对复杂推理任务开启 thinking

同一个格式转换任务：

输入 Token: 500
可见输出 Token: 200
thinking Token: 0
总输出计费: 200 Token

节省效果：输出侧 Token 减少约 91%。 对于简单任务，thinking 不仅会抬高成本，也会显著增加延迟。

---

五、输出控制：减少模型的"废话"

输出 Token 通常比输入贵 3-6 倍。控制输出长度是降本的高杠杆点。

1. 限定输出格式

❌ 优化前：自由格式回答（约 300 Token 输出）

User: 这个订单的状态是什么？
Assistant: 您好！感谢您的询问。我来帮您查看一下订单状态。
经过查询，您的订单号为 #12345 的订单目前处于"已发货"状态。
该订单已于2024年3月15日从我们的仓库发出，预计将在3-5个
工作日内送达。您可以使用快递单号 SF1234567890 在顺丰官网
查询物流信息。如果您还有其他问题，请随时告诉我！

✅ 优化后：要求结构化输出（约 60 Token 输出）

系统提示中增加：输出JSON格式: {status, shipped_date, tracking_no, eta}

{"status":"已发货","shipped_date":"2024-03-15",
"tracking_no":"SF1234567890","eta":"3-5工作日"}

节省效果：输出 Token 减少约 80%。 结构化输出不仅能减少 Token 消耗，也更便于程序稳定解析。

2. 设置 max_tokens 防止超长输出

即使提示词已经要求简洁，模型有时仍会"发挥过度"。设置 max_tokens 是最后一道防线。

// 分类任务：输出不应超过 20 Token
await openai.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [...],
  max_tokens: 20
});

这通常不会影响模型质量——如果任务本身只需要短输出，max_tokens 只是防止回答意外拉长。

---

六、架构设计：从系统层面控制成本

多层架构：规则拦截 → 语义缓存 → 模型兜底

以上是单次请求层面的优化。到了系统架构层面，还有几个影响更大的设计决策。

1. 结果缓存：相同问题不重复调用

❌ 优化前：每次相同问题都调用模型

用户A问: "你们的营业时间是？" → 调用模型 → 消耗 Token
用户B问: "营业时间几点？" → 调用模型 → 消耗 Token
用户C问: "什么时候开门？" → 调用模型 → 消耗 Token

✅ 优化后：语义缓存 + TTL

用户A问: "你们的营业时间是？"
  → embedding相似度搜索 → 未命中 → 调用模型 → 缓存结果
用户B问: "营业时间几点？"
  → embedding相似度搜索 → 命中 → 直接返回缓存 → 0 Token
用户C问: "什么时候开门？"
  → embedding相似度搜索 → 命中 → 直接返回缓存 → 0 Token

节省效果： 如果 30% 的问题可以通过语义缓存命中，整体模型调用量就能直接减少 30%。而 Embedding 的成本通常远低于生成式模型调用。

2. 预处理层：能不用模型就不用模型

❌ 优化前：所有请求都进模型

"你好" → 模型处理 → "你好！有什么可以帮助您的？"
"谢谢" → 模型处理 → "不客气！还有其他问题吗？"
"#@!$%" → 模型处理 → "抱歉，我没有理解您的意思"

✅ 优化后：规则层拦截 + 模型兜底

"你好" → 规则匹配 → 固定回复（0 Token）
"谢谢" → 规则匹配 → 固定回复（0 Token）
"#@!$%" → 规则拦截 → 固定回复（0 Token）
"我想退款" → 规则未匹配 → 进入模型处理

节省效果： 实际业务中，20%-40% 的对话可以被规则层直接处理，完全不消耗模型 Token。

3. 异步批处理 vs 实时调用

如果你的任务不要求实时返回（如数据标注、内容审核、批量翻译），使用 Batch API 通常可以获得 50% 的价格折扣。

调用方式	延迟	价格
实时 API	秒级	标准价格
Batch API	小时级（通常 24h 内）	标准价格的 50%

---

七、综合案例：一个客服系统的全链路优化

把上面的策略组合起来，看一个完整的案例。

假设一个电商客服系统：

• 日均 10,000 次对话
• 平均每次对话 5 轮
• 系统提示词 2000 Token
• 每轮用户输入约 100 Token，模型输出约 300 Token

优化前的日均成本估算

每轮输入 ≈ 2000（系统提示）+ 累积历史（平均约 1500）+ 100（用户输入）= 3600 Token
每轮输出 ≈ 300 Token
每次对话 5 轮总输入 ≈ 18,000 Token
每次对话 5 轮总输出 ≈ 1,500 Token

日均总输入 = 10,000 × 18,000 = 1.8 亿 Token
日均总输出 = 10,000 × 1,500 = 1,500 万 Token

使用 GPT-4o（$2.5/1M 输入，$10/1M 输出）：
日均成本 = 180 × 2.5 + 15 × 10 = $450 + $150 = $600

优化后的日均成本估算

应用以下策略组合：

1. 提示词精简：2000 → 800 Token
2. 滑动窗口（保留 3 轮）：平均历史从 1500 降到 600 Token
3. 缓存命中（前缀稳定）：800 Token 系统提示 90% 命中缓存
4. 模型路由：85% 简单任务用 GPT-4o-mini
5. 输出结构化：输出从 300 降到 120 Token
6. 规则层拦截：30% 对话不进模型
7. 语义缓存：额外命中 15%

实际进入模型的对话 = 10,000 × (1 - 0.30 - 0.15) = 5,500 次

每轮输入 ≈ 80（未缓存提示）+ 720（缓存提示，按0.1计）+ 600 + 100 = 852 等效 Token
每轮输出 ≈ 120 Token
每次对话 5 轮总等效输入 ≈ 4,260 Token
每次对话 5 轮总输出 ≈ 600 Token

其中 85% 用 GPT-4o-mini，15% 用 GPT-4o：

mini 部分：
输入 = 5,500 × 0.85 × 4,260 = 约 2,000 万 Token × $0.15/1M = $3
输出 = 5,500 × 0.85 × 600 = 约 280 万 Token × $0.6/1M = $1.7

4o 部分：
输入 = 5,500 × 0.15 × 4,260 = 约 350 万 Token × $2.5/1M = $8.8
输出 = 5,500 × 0.15 × 600 = 约 50 万 Token × $10/1M = $5

日均总成本 ≈ $3 + $1.7 + $8.8 + $5 = $18.5

📊 优化效果汇总

• 优化前日均成本：$600
• 优化后日均成本：$18.5
• 节省比例：约 97%
• 月度节省：约 $17,445

以上数字是基于电商客服场景的理想化综合估算，实际效果仍取决于业务形态、流量结构与实现质量。但即使只达到其中一部分优化收益，节省幅度也往往足够可观。

---

八、策略选择优先级

不同策略的实施难度和收益差异很大。如果你不确定从哪里开始，可以参考这个优先级：

优先级	策略	实施难度	预期收益
🥇 最先做	模型路由（大小模型分流）	低	非常高
🥇 最先做	提示词精简	低	高
🥈 其次做	输出格式控制	低	高
🥈 其次做	缓存前缀优化	低	中-高
🥉 然后做	上下文滑动窗口	中	高
🥉 然后做	规则层拦截	中	中
🏅 长期建设	语义缓存	高	中-高
🏅 长期建设	历史摘要压缩	高	中

---

九、结论：省 Token 的本质是工程能力

回顾整篇文章，所有优化策略本质上都在做同一件事：

让模型只处理它真正需要处理的信息，只生成你真正需要的输出。

这不是某个神奇的参数配置，而是一整套工程实践：

• 提示词工程解决的是"少说废话"；
• 上下文管理解决的是"别重复带货"；
• 缓存策略解决的是"重复的东西别全价付"；
• 模型路由解决的是"杀鸡别用牛刀"；
• 架构设计解决的是"能不调模型就别调"。

上一篇讨论的是“钱是如何花出去的”，这一篇讨论的是“成本如何系统地降下来”。两篇结合起来，基本可以构成对大模型成本问题的完整认知闭环。

需要强调的是：省 Token 本身不是目的，在可接受的质量前提下降低 Token 成本，才有实际意义。 任何优化都不应以明显牺牲用户体验或输出质量为代价。在推进每一项优化时，都应该同步监控质量指标，确保成本下降不是以服务质量下滑换来的。

附：一个可实际体验的中转站选择

如果你想把本文的策略（提示词精简、上下文裁剪、缓存命中、模型路由、输出控制）真正落到工程里，最有效的办法之一是找一个计费透明、统计清晰、便于切模型与观察缓存的平台，做几组小实验把“优化前 vs 优化后”的差异跑出来。

如果你最近刚好在找可用的中转站，也可以参考我朋友超哥在做的 Amux API。它更适合用来做这些验证：

• 多模型统一接入：便于做“大小模型分流”的对比；
• 成本与用量更直观：方便核对输入、输出、缓存命中后的计费差异；
• 更贴近真实账单：用同一套业务请求去验证“前缀稳定”“输出变短”等策略的实际收益。

选平台时，建议仍按本文标准做取舍：不仅看倍率，也要看充值口径、缓存表现、计费透明度和稳定性。

写在最后🧪

这里是言萧凡的 AI 编程实验室。 我会在这里持续记录和分享 AI 工具、编程实践，以及那些值得沉淀下来的高效工作方法。 不只聊概念，也尽量分享能直接上手、能够复用的经验。 希望这间小小的实验室，能陪你一起探索、实践和成长。2026 年，一起进步。

36氪获悉，天数智芯发布港股上市后首份2025年业绩报告，公司全年实现营收10.34亿元，同比增长91.6%；毛利5.58亿元，同比增长110.5%，毛利增速高于营收增速，产品盈利能力稳步提升。经调整净亏损同比收窄32.1%，研发与经营效率同步改善，财务结构稳健，业绩实现高质量增长。

36氪获悉，三一重工发布2025年业绩报告。报告显示，2025年实现营业收入892.31亿元，同比增长14.73%；归属于上市公司股东的净利润84.08亿元，同比增长41.18%；基本每股收益0.9834元。董事会同意以公告实施2025年年度利润分配的股权登记日当天的总股本，在扣除回购专用账户中的回购股份数后为基数，向股权登记日在册全体股东每10股派发1.8元现金红利（含税）。本利润分配预案尚须提交股东会审议。

36氪获悉，热门中概股美股盘前多数走强，截至发稿，爱奇艺涨超11%，蔚来涨超3%，小鹏汽车涨超1%，京东、网易涨近1%，拼多多涨0.54%，理想汽车涨0.4%，百度涨0.05%；B站跌0.54%。

在理想、问界、蔚来等品牌不断改写中国新能源 SUV 市场格局的时候，燃油车时代长期占据主导位置的大众，实际上错过了这一轮行业切换中最关键的几年。

问题不在于大众完全没有察觉趋势，而在于它始终没能把判断快速转化为稳定的产品节奏。战略摇摆、决策迟缓，再加上 CARIAD 长期拖住软件与电子电气架构的落地进度，让大众一次次错过本该抓住的窗口。

等它还在解决体系内部的问题时，中国新能源市场已经进入了新的竞争阶段。用户看重的不只是品牌、机械素质和制造体系，还加上了产品定义、智能化体验，以及迭代速度等能力。

大众过去那套依靠品牌积累和工程口碑逐步建立优势的方法，在这样的环境里，显然已经不够用了。

留给合资品牌的机会已经不再宽松，甚至可以说，每往后一步，试错空间都在变小。

所以，ID. ERA 9X 的出现，意义并不只是「大众终于出了一台新的大型增程 SUV」，也不只是补上一款旗舰车型那么简单。

它更像是大众第一次真正放下过去的路径依赖，开始按照中国市场已经形成的新规则来重新组织产品。

大众 ID. ERA 9X 全系标配四驱，共有 3 个版本，起售价为 32.98 万元。

最大的大众

外观，是 ID. ERA 9X 递给市场的第一张名片。

该车型在设计上结合了包豪斯功能主义风格。车身比例设定为 4 倍轮轴比、2.5 倍轮高比以及 1:2 的窗身比，旨在降低视觉重心并拉长侧面轮廓。

车身线条由贯穿式肩线、下压式车顶弧线以及上扬的裙线构成，外覆盖件多采用连续饱满的曲面进行过渡，取代了传统的锋锐折线。

车头配备贯穿式灯带，并在侧翼集成双排投影灯，可与车辆解锁及闭锁状态联动。

来到车身侧面，设计师通过对全车立柱的黑化处理，巧妙营造出悬浮式车顶的视觉效果，在保留旗舰 SUV 厚重气场的同时，为车身线条注入了一丝轻盈感。

此外，车门配备了电吸功能，后门最大开门角度设定为 80°，配合低地板设计，有效优化了乘员上下车的动线。

新车长宽高分别达到 5207/1997/1810mm，轴距更是长达 3070mm。这一越级身形超越了揽境，使其一跃成为大众品牌全球在售体型最大的 SUV。

如果说磅礴的外观是敲门砖，那么 ID. ERA 9X 的座舱，则是其真正展现「本土化诚意」的核心答卷。

依托 3070mm 的超长轴距与方正的车身结构，乘员可更为顺畅地步入采用三排六座布局的座舱。

乘员舱一至三排的纵向空间数据为 2650mm，第一排至第二排最大间距达 1960mm；在满载状态下，第二排与第三排的膝部空间分别为 70mm 和 50mm。

全车还规划 40 处储物空间，涵盖门板双层储物盒（含雨伞格）、墨镜盒以及各座位独立的手机槽、USB 接口和杯托，中控区域则集成了一台支持双向开启的智能冷暖压缩机冰箱。

同时，车内支持 6 种空间布局切换，第三排座椅放倒后可与后备箱地板平齐，配合全系标配的带独立电动遮阳帘的前后双全景天窗，进一步拓展了座舱的通透感与空间实用性。

在宽绰的空间基础之上，车内的乘坐系统着重提升了舒适度。

第二排配备动态零重力座椅，因集成了随动安全带与坐垫气囊，该功能在车辆行驶过程中亦可开启。

全车座椅表面采用 Nappa 真皮包覆，内部以 MDI 高弹发泡材质与丝绵填充，并配有独立的颈部支撑软垫。

在功能层面，座椅支持坐垫与靠背的分区智能温控调节，一、二排的靠背、座垫及腿托均具备独立加热功能。同时，座椅内置 16 点阵式按摩系统，预设 11 种模式，并标配 4 向可调腰托。

物理层面的舒适配置之外，座舱的数字化则是另一块核心。

车内搭载由 9 个显示终端组成的系统，包含 8.88 英寸仪表盘、15.6 英寸 2.5K 中控双联屏、21.4 英寸 3K 后排可调吸顶屏、流媒体后视镜以及支持随速动态调整显示层级的 W-HUD 抬头显示系统。

第二排两侧门板各内嵌一块 6 英寸控制屏，采用微孔膜片技术实现息屏时的视觉隐藏，主要用于调节后排温度、座椅及冰箱，并接入了外后视镜的盲区摄像头画面以辅助开门观察。

车机系统支持多屏内容流转，并可通过 OMS 摄像头实现手势控车。语音系统覆盖 4 个独立音区，具备声源定位、方言识别以及车外防误唤醒功能，同时内置了定制化虚拟语音助手。

车辆还配备了 Carlog 功能，可通过多机位摄像头记录行车画面，中控 UI 则采用了 3D 全景实况渲染技术。

声学与照明系统也进一步完善了座舱的整体氛围。

车内配备 4 个独立头枕音响，支持各座位分区独立听音及车载 K 歌功能；车外配置的独立发声单元，不仅用于行人警示，还支持车内外双向语音沟通及户外场景的音乐播放。

车内布置了总长 12.8 米的 255 色氛围灯，采用漫反射导光方案隐藏光源直射，以提供更为均匀的光线。该灯组支持色彩自定义及主题切换，并可与开门预警、迎宾、驾驶模式切换、空调调节、自动泊车及语音交互等车辆运行状态进行深度联动。

从 AR-HUD 抬头显示、二排零重力座椅、智能冷暖冰箱，到支持四音区独立唤醒的智能语音系统、5G 车联网以及主动降噪技术，ID. ERA 9X 的座舱配置已全面对齐国产高端新势力，彻底补齐了以往合资品牌在舒适体验与科技感上的短板。

在消费者日益看重的智驾领域，大众果断选择了成熟的「中国方案」。

新车搭载了由 Momenta 深度赋能的高阶智驾系统。在车顶激光雷达、毫米波雷达与高清摄像头等强大硬件的加持下，新车能够实现涵盖高速、城市以及点到点的全场景无图 NOA 领航辅助。

无论是自动跟车、智能变道，还是复杂场景下的智能泊车与开门预警，其智驾表现均已跻身行业第一梯队。

纯正德系旗舰

ID. ERA 9X 的动力总成与底盘调校，则是大众将深厚德系工程底蕴与中国本土需求完美融合的最佳印证。

新车搭载了专为增程车型研发的 EA211 EVO II 系列 105kW 发动机，官方自信地将其誉为「地表最强增程器」。

通过集成米勒循环、VTG 可变截面涡轮以及 350bar 高压直喷等先进技术，该增程器在亏电工况下的动力衰减仅约 5%。

即便在零下 30℃ 的极寒环境中，其零百加速依然能达到 6.31 秒，且增程器介入时的舱内噪音增量不到 0.5 分贝（dB），真正做到了无感介入。

针对增程式动力特有的 NVH（噪声、振动与声振粗糙度）工况，该车从声源抑制与主动降噪两方面进行了技术介入。

在声源端，EA211 增程器采用了紧耦合排气净化装置，旨在降低排气系统的机械共振。在座舱端，车辆在全车密闭隔音设计的基础上搭载了 ANC 主动降噪技术。

根据相关的冬季实测数据，在亏电状态并换装雪地胎的测试环境下，车内噪音峰值维持在 58dB 以内；同时，在增程器介入与关闭的切换过程中，第二排乘客位置的噪音波动差值被控制在 0.5dB 以下，平滑了内燃机启停时的听觉感知。

电池方面，大众提供了 51.1kWh 磷酸铁锂与 65.2kWh 宁德时代三元锂两套方案，CLTC 工况下最高纯电续航超过 400km，综合续航里程更是突破 1000km。

为了让这台长达 5.2 米的庞然大物在城市中穿梭自如，大众为其配备了越级的底盘系统。

该车采用了前双叉臂与后五连杆的独立悬架组合。其中，前悬架配备锻铝下摆臂，后悬架采用「五铝一钢」的连杆材质配比，前后桥均布置有四点液压衬套。通过提升铝合金部件的占比，车辆有效降低了簧下质量并增强了底盘的整体刚性。

悬挂系统配备了双腔空气弹簧与 DCC 无级可调减振器，支持车身高度与阻尼硬度的毫秒级自适应调节。其空气悬架的最大调节行程达到 150mm（支持向上升高 80mm 以提升通过性，或向下降低 70mm 以方便乘员上下车）。

得益于后轮转向技术的加入，ID. ERA 9X 的最小转弯半径大幅缩减至 5 米左右，让这款大型 SUV 在狭窄地库中的操控灵活性足以媲美紧凑型轿车。

而为了为了统筹上述复杂的底盘硬件，车辆在控制逻辑层面引入了 VMC 底盘智控中枢。该系统将底盘的制动、驱动、转向、悬架及动力控制进行了全域数据融合，可实现车辆在横向、纵向及垂直三个维度（六自由度）的综合运动协同与干预。

安全性方面，ID. ERA 9X 车身关键部位采用了强度高达 1300MPa 的热成型钢；电池包获得 IP68 级防尘防水认证，并顺利通过了挤压、针刺、火烧、涉水等严苛测试。

同时，全车标配多安全气囊与侧气帘，并搭载了车身稳定系统、胎压监测、上坡辅助、防翻滚系统等丰富的安全配置，全方位守护出行安全。

从公开质疑增程，到发布一台增程旗舰，大众用了不短的时间才完成这次转身。

尽管过程有曲折，但 ID. ERA 9X 显然放下了合资品牌之前高高在上的身段，认真思考了中国用户到底需要什么。

ID. ERA 9X 认真对待了中国用户对空间的需求，把三排真正做成了可以长途乘坐的座位；认真改进了增程系统的缺陷，在 NHV 和动力衰减上做了补足；它也认真对待了座舱体验与竞品之间的差距，和合作伙伴一起，把中国用户需要的配置一一补齐。

不过，这个时间点并不轻松。

大众现在面对的，不是一个等待开拓的新市场，而是一个格局已经初步成形、用户认知已经被教育过、头部品牌已经各自占住位置的市场，它要追赶的，远不只是销量。

不过，好在 ID. ERA 9X 目前看来，很值得期待。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

36氪获悉，美股大型科技股盘前多数上涨，截至发稿，亚马逊、Meta、特斯拉涨超1%，英伟达、谷歌、微软涨近1%，Arm涨0.61%，苹果涨0.26%；奈飞跌0.37%。

36氪获悉，领湃科技公告，公司拟向衡阳五强动力有限公司转让全资子公司湖南领湃新能源研究院有限公司100%股权，本次股权转让价格为人民币1元。以2026年1月31日为评估基准日，领湃研究院于评估基准日股东全部权益价值为人民币-9.45万元。双方经公平、友好协商，以领湃研究院实际资产负债状况为基础，并根据评估价值，最终确定本次股权转让价格为人民币1元。

今天，vivo 一口气交出了两份旗舰手机的答卷：除了主打全能的 X300s，更重磅的看点，是当家影像旗舰 X300 Ultra。

在移动影像卷生卷死的时代，一台被官方冠以「影像灭霸」和「V 单」称号的手机，拿出了它打磨三代后的版本答案：两颗 2 亿像素摄像头，翻倍到 400mm 的增距镜，和前所未有的专业视频模式。

过去一段时间里，爱范儿深度体验了 vivo X300 Ultra，我们试图从一个摄影师的视角，去理解 vivo 关于移动影像的最新答案。

比 2 亿像素更好的，是 2 亿像素加倍

一台设备能不能拍好照片，首先取决于你愿不愿意带出家门，上手 vivo X300 Ultra 的第一时间，我们照例看看它的外观设计。

总得来说，X300 Ultra 基本延续了一贯的家族式设计，但在小细节上有所不同——手机中框采用四曲包边设计，手感比较柔和；手机背部的影像 Deco 增加了一个比边缘略小一圈的火山口过渡，在视觉上起到收拢作用；刻度纹依旧保留，为 Deco 保持精致。

在凸起的影像 Deco 中，vivo X300 Ultra 搭载了以 14mm 超广角、35mm 主摄以及 85mm 长焦，基本保持前代的焦段方案，彻底夯实「手机大三元」战略。

维持住经典焦段组合的同时，这套「大三元」迎来了本次最核心的升级：主摄与长焦双双跨入了 2 亿像素大关——这也是 vivo 自 X100 系列首次采用 2 亿像素镜头后，又一次加码押注 2 亿像素。

在手机刚搭载上亿像素的传感器时，有一个「像素陷阱」——

在当时的语境里，画面质量更多取决于传感器大小，单纯堆砌像素只会被视作糊弄外行的数字游戏。

但当手机内部空间已经极大让渡给影像，传感器尺寸大到足以支撑高像素时，用高像素换高画质，就成了唯一行得通的路径。

对于日常拍照来说，高像素最核心的意义，就是给了你后期随意裁切的物理底气。 35mm 1/1.12 英寸主摄和 85mm 1/1.4 英寸长焦的超高像素为传感器提供了宽裕的画面保留空间，就算你拍完之后只截取画面中心的一小部分，细节依然扎实。

不过，2 亿像素更多还是象征意义，毕竟日常出门很少有人愿意顶着 2 亿像素的巨大文件体积连续按快门。

因此，vivo 设定了更实用的输出逻辑：系统默认拍摄 1200 万像素，同时开放 2500 万和 5000 万像素的档位供你手动选择。

更高像素带来的增益是明显的，用 5000 万像素拍下的照片，画面的清晰度会跟 1200 万像素拉开肉眼可见的差距。

抛开高像素的硬指标，色彩是这台机器的另一大看点。

新加入的「浓郁」与「追光」风格，色彩逻辑分别脱胎于理光的正片与负片。这两套风格极具辨识度，配合高像素的扎实细节，实拍质感相当抓人。

之前几代产品，2 亿像素传感器依然存在一些优化问题——虽然解析力高，但处理画面所需的等待时间长，很打断拍摄的流畅度。

在这一代上，vivo 优化了体验上的问题，将处理管线放在了相册后台中，拍摄时不会再有阻塞感。

除了两颗 2 亿像素外，vivo X300 Ultra 的焦段还得到了进一步拓展——前代，vivo 专门设计了一颗外挂增距镜，将手机的光学焦段拓展到 200mm，而在这一代上，vivo 首先是将 200mm 的增距镜瘦身到比一管口红还小，与此同时，加入了一枚堪称疯狂的 400mm 增距镜。

用起来怎么样？

实话说，非常挑，也非常好——

400mm 增距镜的主要场景，还是聚焦在演唱会等特殊环境。如果你打算带着它去扫街，很抱歉，在高楼密布的街道里，400mm 的焦段会让画面非常逼仄，几乎没有用武之地。

而如果你将它带去打鸟，面对真实的生态场景它也稍显局促，若是在复杂环境中，将焦段裁切到 800mm 的话，很容易失焦——无论是对手机，还是对摄影师的手，都提出了更高的要求。

但从成像效果来看，400mm 的增距镜也确实带来了更极致的长焦表现，尤其是在演唱会这样的特化场景里：

顺带一提，即便在挂上增距镜的极限状态下，实况照片功能也并没有被阉割。这让你在演唱会等特殊场景中，多了一种更鲜活的记录手段。

除了实况照片，我们还非常推荐在使用 400mm 增距镜时打开 2500 万、5000 万甚至 2 亿像素档位，会让解析力更进一步。

话说回来，虽然目前体验尚有瑕疵，但我还是想肯定 400mm 的意义——常话说「拍到比拍好更重要」。影像最基础的底线是记录，在「彻底拍不到」和「画质有点糙但拍到了」之间，答案根本不需要犹豫。

相机交互更好了，但没到最好

相机交互设计，是所有影像旗舰手机都面临的老大难问题——相机功能太多、但屏幕位置太少。

对于把影像能力推到极致的 vivo X300 Ultra 而言更是如此。

在这一代上，vivo 重新设计了整个相机 UI，二级菜单逻辑变化尤为明显。

在往代机型上，二级菜单（与拍摄相关的设置）都放在屏幕顶部中。而在 vivo X300 Ultra 上，二级菜单图标放到了取景框的右下角，也就是焦段选择的右边，图片比例、倒计时、原生光影和抓拍等设置都在其中，而顶部则保留了闪光灯、实况照片、微距、两亿像素开关这类与实时拍摄关联性更强的设置，方便用户快捷操作。

不过，表面的重构没能理顺底层的臃肿。新 UI 里依然充斥着逻辑冗余：取景框右下角已经常驻了「抓拍」和「风格」按钮，滑开二级菜单，它俩居然还在占位置。

为了应对这种混乱，vivo 开放了自定义权限。通过二级菜单最末尾的「编辑」功能，你可以手动增减、重排各个区域的快捷键，借此来适配自己的拍摄习惯。

iPhone 的诞生，让手机一举迈向智能机时代。此后，所有的交互都逐渐搬移到屏幕上。这对影像而言，这其实不算好事。

专业相机功能繁杂，作为应对，厂家用花样繁多的物理按键来给多样化的功能安家——按键、旋钮、拨杆……不一而足。但对于手机而言，物理按键的消失是既定趋势，日益复杂的功能被塞进了一块玻璃屏幕里，只能靠一层层的二三级菜单承载五花八门的设置。

更何况，这一代 X300 Ultra 还砍掉了普通用户风评不算好的操作按钮和相机控制按钮，实体按键更少了，屏幕操作空间也更局促了。

但交互上的冲突并非没有办法解决，在分析 iOS 26 的 UI 设计中，我们就找到一个不错的方案：https://mp.weixin.qq.com/s/6hM-gYyafpdEOzDK_1gFKQ

相较静态照片来说，vivo 为视频专门设计的「专业录像 Pro 模式」，显得自洽很多。

在录像模式的录制键右侧，出现了一个写着「Pro」的录像机图标，点击这个图标，就进入了专业录像 Pro 模式。

将手机横置后，这套专业界面的排布逻辑显得非常清晰。 左手边主要负责全局控制，依次是模式设置、预览切换、增距镜开关及退出键；

右手边则完全留给了核心操作，集中排布着视频规格、曝光补偿（EV）、焦段、对焦以及二级设置入口。

视线回到取景框，顶部干净地罗列着分辨率、帧率、快门、ISO 与色温等关键参数；底部两侧则留给了监看工具——左下角实时显示麦克风收音电平与剩余存储空间，右下角则是直方图与电量状态。各功能区互不干扰，井井有条。

实际体验下来，专业录像 Pro 模式的完成度相当高。快门、ISO 与白平衡均支持自动与手动双轨控制，防抖与画幅等基础功能一应俱全，内置的峰值对焦也极大降低了手动跟焦的门槛。

右侧菜单顶部预留了 Log 与 Rec.709 的快捷切换键，不仅支持官方 LUT 实时监看，还能直接导入你个人常用的 LUT 文件预览最终成色。

可以说，在专业录像 Pro 模式下，vivo X300 Ultra 已经具备了一定的生产力。

这几年打磨下来，靠着高像素和生猛的外挂长焦，vivo 在静态拍照上确实稳住了基本盘。

而随着专业录像 Pro 模式的加入，意味着 vivo 开始向视频生产工具探路。除了最高 8K 的录制规格，这台机器放开了全焦段的 4K 120 帧 Log 选项，为后期留足了明暗拉扯的宽容度。

至于它的实际表现如何，后续我们还会有一条体现 vivo X300 Ultra 视频性能的短片，大家可以一见分晓。

影像手机，终于成了相机

在文章的最后，我想提一个手机之外的有趣事情。

拿到这台 vivo X300 Ultra 时，编辑部里的人不少。每一个拿起手机的人，第一反应总是看看增距镜、拿在手上体验体验、拍一拍，没人再去纠结配置。

看待影像旗舰手机的视角，已经出现了微妙的转变。

过去几年的手机影像评测，大家习惯性死磕几个数字：底有多大、单像素面积多少、进光量提升了多少。

但发展到今天，物理限制促成了一种共识：手机内部的空间见顶了，在厚度与重量的死局里，传感器很难再变出违背物理法则的戏法。

这种不再纠结参数的心态，和我平时拿起一台真正的相机时如出一辙。作为一个影像创作者，当我摸到一台新的全画幅或 APS-C 微单时，根本不会去查阅它的 CMOS 规格表。

我心里很清楚，全画幅就是全画幅，半画幅就是半画幅，它的基础画质上限就在那里，不会突然跳出一个颠覆认知的奇迹。

相对的，拿到相机后，我只关心「干活」的体验：机身握持是否扎实？菜单逻辑符不符合直觉？配套的镜头群到底好不好用？

毕竟相机从来不是一块孤立的 CMOS，而是由镜头群、色彩科学和专业工作流构成的完整系统，而这恰恰是 vivo X300 Ultra 的发力方向——用 400mm 增距镜丰富物理焦段、用克制的算法取代粗暴的暗部提亮，再加上电影机规格的录像界面。

vivo X300 Ultra，正试图从单纯的硬件堆砌，进化成一套能打硬仗的影像系统。

也正是因为如此，我看待这台手机的逻辑也有了变化——全新的 UI 界面，在拍摄时会不会让我手忙脚乱？系统各项高频功能，呼出够不够顺手？400 毫米增距镜，能不能帮我在复杂环境里带回有用的画面？

vivo X300 Ultra 并不完美——

作为一台相机，它的交互依然有繁冗之处，极端焦段的体验也还在打磨。

作为一台手机，它的硬件配置已经不再让人纠结，取而代之的，是摄影师挑剔的眼光。

当我们以相机的要求，去审视一部手机的操控逻辑、镜头搭配和界面自洽时，事情就已经悄然发生变化——

手机摄影在我们都没察觉的时候，已然跨过靠参数搏杀的门槛。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

36氪获悉，美的集团公告，公司董事会审议通过回购方案，拟以集中竞价方式回购A股股份，回购金额不低于65亿元且不超过130亿元，回购价格不超过100元/股。回购资金来源于公司自有资金及中国银行顺德分行提供的专项贷款(贷款不超过回购金额90%)。回购股份将用于实施股权激励计划及/或员工持股计划，期限自董事会通过之日起12个月内。

JavaScript 闭包经典问题：为什么输出 10 次 i=10

问题代码

先观察以下代码，思考输出结果：

function f() {
    for(var i = 0; i < 10; i++) {
        setTimeout(() => {
            console.log('i=', i)
        });
    }
}

f();

输出结果：

i= 10
i= 10
i= 10
...（共 10 次）

---

执行过程详解

第一步：var 变量的作用域

for(var i = 0; i < 10; i())
    ↑
    └── var 声明的变量是函数作用域
        整个函数 f 内都能访问这个 i

第二步：循环执行过程

循环次数     i 的值    循环条件 (i < 10)
---------------------------------------
第 1 次      0         ✓ 通过
第 2 次      1         ✓ 通过
...
第 10 次     9         ✓ 通过
             10        ✗ 不通过，循环结束

循环结束后：i = 10

第三步：创建 10 个回调函数

for(var i = 0; i < 10; i++) {
    setTimeout(() => {
        console.log('i=', i)  // ← 所有回调共享同一个 i
    });
}

每次循环创建一个箭头函数，都通过闭包引用变量 i

第四步：异步执行时序

时间轴：
─────────────────────────────────────────
| 同步执行阶段        | 异步执行阶段        |
─────────────────────────────────────────
for 循环完成      setTimeout 回调执行
i 递增到 10       读取 i 的值（此时 i=10）
                  输出 10 次 i=10
─────────────────────────────────────────

---

核心原因

三个关键点

1. var 是函数作用域

   • 不是块级作用域
   • 整个函数内只有一个 i 变量

2. 闭包共享变量

   • 10 个箭头函数都引用同一个 i
   • 不是创建 10 个独立的 i 副本

3. setTimeout 异步执行

   • 回调函数放入任务队列延迟执行
   • 执行时循环已结束，i 已经是 10

图示理解

变量 i 的生命周期：
─────────────────────────────→ 时间
     0 1 2 3 4 5 6 7 8 9  10
     └───┬───┘ └───┬───┘
         │                │
     同步循环执行        循环结束
                        i=10

回调函数 1:  ────────────────────→ 读取 i (10)
回调函数 2:  ────────────────────→ 读取 i (10)
...
回调函数 10: ────────────────────→ 读取 i (10)

---

解决方案

方案 1：使用 let（推荐）✨

function f() {
    for(let i = 0; i < 10; i++) {
        setTimeout(() => {
            console.log('i=', i)
        });
    }
}

原理： let 是块级作用域，每次循环创建新的 i 绑定

输出： i= 0 到 i= 9 各一次

---

方案 2：IIFE 立即执行函数

function f() {
    for(var i = 0; i < 10; i++) {
        (function(j) {
            setTimeout(() => {
                console.log('i=', j)
            });
        })(i);
    }
}

原理： 通过函数参数保存每次循环的 i 值

---

方案 3：传递参数给 setTimeout

function f() {
    for(var i = 0; i < 10; i++) {
        setTimeout((j) => {
            console.log('i=', j)
        }, 0, i);
    }
}

原理： setTimeout 的第三个参数会传递给回调函数

---

知识点总结

概念	说明
var 作用域	函数作用域，非块级作用域
let 作用域	块级作用域，每次循环创建新绑定
闭包	函数可以访问其声明时所在作用域的变量
异步	setTimeout 的回调会延迟执行
共享引用	同一作用域的闭包引用同一个变量

---

一句话总结

var 的函数作用域 + 闭包共享变量 + setTimeout 异步执行 = 所有回调读取到循环结束后的同一个 i 值（10）

36氪获悉，顺丰控股公告，公司董事会同意将2025年第1期A股回购股份方案的回购资金总额由“不低于人民币15亿元且不超过人民币30亿元”调整为“不低于人民币30亿元且不超过人民币60亿元”，将回购实施期限延长至董事会审议通过变更回购方案之日起12个月止，同时将回购股份用途从“用于员工持股计划或股权激励”变更为“用于注销并减少注册资本”。

一名同时精通 Blender 建模与 Three.js 渲染的工程师，带你打通从艺术创作到 Web 实时渲染的全链路。

---

前言

很多开发者在学习 Three.js 时，习惯用代码"画"出几何体——一个 BoxGeometry，一个 SphereGeometry，就此打住。而建模师则沉浸在 Blender 的雕刻与材质世界里，对 Web 端渲染一无所知。

真正有价值的 3D Web 项目，往往需要这两者的深度结合：Blender 负责内容生产，Three.js 负责实时呈现。本文将从工作流、格式选择、材质映射、性能优化到动画同步，系统拆解这套协作体系的每一个关键节点。

---

一、为什么选择 Blender + Three.js？

Blender 的优势

Blender 是目前最强大的开源 3D 创作套件，集建模、雕刻、UV 展开、材质编辑、骨骼绑定、动画、渲染于一体。它的 PBR（基于物理的渲染）材质系统与 Three.js 的 MeshStandardMaterial 有高度的理论对应关系，这使得材质迁移成为可能，而非只能靠"近似"。

Three.js 的优势

Three.js 是 WebGL 的高级封装，让开发者无需手写 GLSL Shader 就能实现实时 3D 渲染。它支持 glTF 2.0 标准、骨骼动画、变形动画、PBR 材质、HDR 环境贴图，在浏览器端提供接近原生的视觉质量。

两者的天然契合点

特性	Blender	Three.js
材质模型	Principled BSDF	MeshStandardMaterial
动画系统	Action / NLA	AnimationMixer
导出格式	glTF 2.0 原生支持	GLTFLoader 原生支持
坐标系	Y-up（可配置）	Y-up
PBR 贴图	BaseColor / Roughness / Metallic / Normal	map / roughnessMap / metalnessMap / normalMap

glTF 2.0 是连接两者的"通用语言"，它由 Khronos Group 制定，Blender 对其有完整的原生导出支持，Three.js 也将其作为首推格式。

---

二、Blender 建模的 Web 友好实践

在 Blender 中建模时，如果目标是 Web 端实时渲染，需要从一开始就考虑"面向 Web 的建模规范"，而不是按离线渲染的标准来做。

2.1 多边形控制：少即是多

离线渲染可以承受千万面模型，但 Web 端 GPU 对三角面数极为敏感。经验值如下：

• 单个主体模型：5,000 ~ 50,000 三角面（取决于镜头距离）
• 背景/远景物体：500 ~ 2,000 三角面
• 整个场景：尽量控制在 300,000 三角面以内（移动端减半）

实用技巧：

在 Blender 中使用 Decimate 修改器可以智能减面，
Ratio 参数从 1.0 逐渐降低，观察模型形变程度，
通常 0.5 ~ 0.7 可在不明显损失细节的前提下大幅减面。

高模细节应通过 法线贴图（Normal Map）  烘焙到低模上，而不是保留在几何体中。这是 Web 3D 最核心的优化手段之一。

2.2 UV 展开的关键性

Three.js 中所有贴图都依赖 UV 坐标。Blender 中的 UV 展开质量直接决定贴图利用率和最终画质。

UV 展开建议：

1. 使用 Smart UV Project 快速处理机械类硬表面模型
2. 有机体（角色、生物）使用 Mark Seam + Unwrap 手动控制接缝位置
3. UV 岛之间保留 至少 4 像素的边距（Margin）  ，防止贴图渗色
4. 避免 UV 重叠（除非是对称模型且确定共用贴图）

2.3 坐标系与朝向

Blender 默认坐标系：Z 轴朝上，Y 轴朝前。 Three.js 坐标系：Y 轴朝上，Z 轴朝向观察者。

在 glTF 导出时，Blender 会自动进行坐标系转换，因此通常不需要手动旋转。但如果你在 Blender 中对模型进行了非标准旋转，导出后可能在 Three.js 中出现方向错误。

最佳实践：  在 Blender 中完成所有变换后，按 Ctrl+A → All Transforms 应用变换，确保对象的 Location/Rotation/Scale 归零。

---

三、PBR 材质：从 Blender 到 Three.js 的精确映射

这是整个工作流中最需要深入理解的环节。

3.1 Principled BSDF 与 MeshStandardMaterial 的对应关系

Blender 的 Principled BSDF 节点是工业级 PBR 着色器，其核心参数与 Three.js 的 MeshStandardMaterial 有如下对应：

Principled BSDF 参数	Three.js 对应属性	说明
Base Color	color / map	基础颜色/漫反射贴图
Metallic	metalness / metalnessMap	金属度（0=非金属，1=纯金属）
Roughness	roughness / roughnessMap	粗糙度（0=镜面，1=完全漫反射）
Normal Map	normalMap	法线贴图（切线空间）
Emission	emissive / emissiveMap	自发光
Alpha	opacity / alphaMap	透明度
Ambient Occlusion	aoMap	环境遮蔽（需要第二套 UV）

注意：  glTF 2.0 格式将 Roughness 存储在贴图的 G 通道，Metallic 存储在 B 通道，合并为一张 metallicRoughnessMap。Three.js 的 GLTFLoader 会自动处理这个细节，开发者无需干预。

3.2 在 Blender 中烘焙 PBR 贴图

当模型使用了复杂的程序化材质（Noise、Voronoi、Wave 节点等）时，需要将其"烘焙"成位图才能在 Web 端使用。

烘焙流程：

1. 选中模型，进入 Cycles 渲染引擎（烘焙必须使用 Cycles）
2. 新建一张空白图像节点（Image Texture），不连接任何节点，只需选中它
3. 在 Render Properties → Bake 中选择烘焙类型：
4. • Diffuse（取消 Direct/Indirect，仅勾选 Color）→ Base Color 贴图
   • Roughness → Roughness 贴图
   • Normal（Space: Tangent）→ 法线贴图
   • Combined → 全局光照效果烘焙（含 AO、阴影，适合静态场景）
5. 点击 Bake，等待计算完成
6. 导出图像为 PNG（法线图）或 JPEG（颜色图，注意法线图不能用 JPEG 有损压缩！）

这里我推荐一个B站的烘焙教材，很不错的。

链接如下：

(www.bilibili.com/video/BV185…)

3.3 法线贴图的空间问题

Blender 默认导出**切线空间（Tangent Space）**法线贴图，Three.js 也默认使用切线空间法线，两者一致，无需额外处理。

但如果你在 Blender 中烘焙了**对象空间（Object Space）**法线贴图，则需要在 Three.js 中将 normalMapType 设置为 THREE.ObjectSpaceNormalMap：

material.normalMapType = THREE.ObjectSpaceNormalMap;

---

四、glTF 导出配置详解

glTF 是连接 Blender 和 Three.js 的核心桥梁，正确的导出配置至关重要。

4.1 .gltf vs .glb

格式	说明	适用场景
.gltf	JSON 文本 + 外部 .bin + 外部贴图	调试、需要单独管理资产
.glb	全部打包为单一二进制文件	生产环境，减少 HTTP 请求

推荐：生产环境使用 .glb，加载更快，管理更简单。

4.2 Blender 导出设置

File → Export → glTF 2.0，关键设置：

Format: glTF Binary (.glb)

✅ Include:
  - Selected Objects（只导出选中对象，避免导出无关物体）
  - Custom Properties（可传递自定义属性到 Three.js）

✅ Transform:
  - Y Up（确保坐标系正确）

✅ Geometry:
  - Apply Modifiers（应用所有修改器，但注意会破坏骨骼绑定）
  - UVs / Normals / Tangents / Vertex Colors
  - Loose Edges / Points（通常取消勾选）

✅ Animation:
  - Animations（导出动画数据）
  - Skinning（导出骨骼绑定）
  - Shape Keys（导出变形目标/Morph Targets）
  - NLA Strips（从非线性动画编辑器导出所有 Action）

✅ Draco Mesh Compression:
  开启后可大幅压缩几何体数据，但 Three.js 需要额外加载 DRACOLoader

4.3 在 Three.js 中加载 glTF

import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js';
import { DRACOLoader } from 'three/examples/jsm/loaders/DRACOLoader.js';

// 配置 Draco 解码器（如果导出时开启了 Draco 压缩）
const dracoLoader = new DRACOLoader();
dracoLoader.setDecoderPath('/draco/'); // 需要将 draco 解码器文件放在此路径

const loader = new GLTFLoader();
loader.setDRACOLoader(dracoLoader);

loader.load(
  '/models/scene.glb',
  (gltf) => {
    const model = gltf.scene;

    // 遍历所有网格，开启阴影
    model.traverse((node) => {
      if (node.isMesh) {
        node.castShadow = true;
        node.receiveShadow = true;

        // 如果使用 HDR 环境贴图，开启环境光反射
        node.material.envMapIntensity = 1.0;
      }
    });

    scene.add(model);
  },
  (progress) => {
    console.log(`加载进度: ${(progress.loaded / progress.total * 100).toFixed(1)}%`);
  },
  (error) => {
    console.error('加载失败:', error);
  }
);

---

五、动画系统深度对接

Blender 的动画系统与 Three.js 的 AnimationMixer 是整个工作流中最复杂的对接点。

5.1 Blender 动画类型与 Three.js 对应

骨骼动画（Armature Animation）

最常见的角色动画类型。Blender 中为骨骼创建 Action，绑定到 Mesh。导出后 Three.js 通过 SkinnedMesh 和 AnimationClip 驱动。

// 加载后获取所有动画
const animations = gltf.animations; // AnimationClip[]
const mixer = new THREE.AnimationMixer(gltf.scene);

// 播放特定动画（如 "Walk" Action）
const walkClip = THREE.AnimationClip.findByName(animations, 'Walk');
const walkAction = mixer.clipAction(walkClip);
walkAction.play();

// 在渲染循环中更新
const clock = new THREE.Clock();
function animate() {
  requestAnimationFrame(animate);
  const delta = clock.getDelta();
  mixer.update(delta); // 关键：每帧更新动画混合器
  renderer.render(scene, camera);
}
animate();

变形目标动画（Shape Keys / Morph Targets）

适用于面部表情、布料变形等。Blender 中的 Shape Key 导出为 glTF 的 Morph Target。

// 访问变形目标
const mesh = gltf.scene.getObjectByName('Face');
console.log(mesh.morphTargetDictionary); // { "Smile": 0, "Blink": 1, ... }

// 直接设置变形权重（0~1）
mesh.morphTargetInfluences[0] = 0.8; // 80% 的 Smile 表情

// 或通过 AnimationMixer 驱动
const smileClip = THREE.AnimationClip.findByName(animations, 'Smile');
mixer.clipAction(smileClip).play();

5.2 动画过渡：crossFadeTo

游戏和交互应用中，动画之间的平滑过渡至关重要：

let currentAction = idleAction;

function transitionTo(newAction, duration = 0.3) {
  if (currentAction === newAction) return;

  newAction.reset();
  newAction.play();
  currentAction.crossFadeTo(newAction, duration, true);
  currentAction = newAction;
}

// 按键触发动画切换
document.addEventListener('keydown', (e) => {
  if (e.code === 'Space') transitionTo(runAction);
});

document.addEventListener('keyup', (e) => {
  if (e.code === 'Space') transitionTo(idleAction);
});

5.3 NLA 编辑器与多 Action 管理

在 Blender 中，推荐使用 NLA（Non-Linear Animation）编辑器将不同 Action（Idle、Walk、Run、Attack）管理在同一骨骼上。导出时勾选 NLA Strips，Three.js 端会收到所有 Action 作为独立的 AnimationClip。

Blender 操作：

1. 在 Dope Sheet 中切换到 NLA Editor
2. 将 Action 下压为 NLA Strip
3. 每个 Strip 对应一个独立动画
4. 确保每个 Action 有清晰的命名（会直接成为 Three.js 中 clip.name）

---

六、灯光与环境：让 Web 端复现 Blender 的视觉效果

6.1 HDR 环境贴图

Blender 中使用 HDR 环境光照（World → Environment Texture），Three.js 中同样支持，且是让模型在 Web 端看起来"专业"的关键。

import { RGBELoader } from 'three/examples/jsm/loaders/RGBELoader.js';

const pmremGenerator = new THREE.PMREMGenerator(renderer);
pmremGenerator.compileEquirectangularShader();

new RGBELoader().load('/hdr/studio_small.hdr', (texture) => {
  const envMap = pmremGenerator.fromEquirectangular(texture).texture;

  scene.environment = envMap;  // 影响所有 MeshStandardMaterial 的反射
  scene.background = envMap;   // 可选：将 HDR 作为背景

  texture.dispose();
  pmremGenerator.dispose();
});

推荐资源：Poly Haven（polyhaven.com/hdris） 提供大量免费高质量 HDR 文件。

6.2 灯光类型对应

Blender 灯光	Three.js 等价
Sun	DirectionalLight
Point	PointLight
Spot	SpotLight
Area	RectAreaLight
World (HDR)	scene.environment

注意：  glTF 导出支持 Point、Spot、Directional 灯光（需开启 KHR_lights_punctual 扩展，Blender 默认勾选），Area Light 不支持直接导出，需在 Three.js 端手动添加。

6.3 阴影质量配置

// 渲染器阴影配置
renderer.shadowMap.enabled = true;
renderer.shadowMap.type = THREE.PCFSoftShadowMap; // 柔和阴影

// 方向光阴影配置
const dirLight = new THREE.DirectionalLight(0xffffff, 1);
dirLight.castShadow = true;
dirLight.shadow.mapSize.width = 2048;  // 阴影贴图分辨率
dirLight.shadow.mapSize.height = 2048;
dirLight.shadow.camera.near = 0.1;
dirLight.shadow.camera.far = 50;
dirLight.shadow.camera.left = -10;
dirLight.shadow.camera.right = 10;
dirLight.shadow.camera.top = 10;
dirLight.shadow.camera.bottom = -10;
dirLight.shadow.bias = -0.001; // 防止阴影痤疮（Shadow Acne）

---

七、性能优化：从 Blender 到浏览器的极致压缩

7.1 纹理压缩：KTX2 + Basis Universal

传统 JPEG/PNG 贴图在 GPU 中需要解码为原始像素，占用大量显存。KTX2/Basis Universal 是可以直接在 GPU 上保持压缩状态的格式，显存占用可降低 4~8 倍。

工具链：

# 安装 KTX-Software
# 将 PNG 转换为 KTX2（UASTC 模式，高质量）
toktx --uastc --uastc_rdo_l 4 output.ktx2 input.png

# Three.js 中加载 KTX2
import { KTX2Loader } from 'three/examples/jsm/loaders/KTX2Loader.js';

const ktx2Loader = new KTX2Loader()
  .setTranscoderPath('/basis/')
  .detectSupport(renderer);

loader.setKTX2Loader(ktx2Loader);

7.2 实例化渲染：InstancedMesh

场景中有大量相同模型（树木、石头、草地）时，使用 InstancedMesh 可以将数千次 Draw Call 合并为一次：

// 在 Blender 中建好单个树木模型，导出后：
const treeGeometry = treeModel.geometry;
const treeMaterial = treeModel.material;

const COUNT = 1000;
const instancedMesh = new THREE.InstancedMesh(treeGeometry, treeMaterial, COUNT);

const dummy = new THREE.Object3D();
for (let i = 0; i < COUNT; i++) {
  dummy.position.set(
    (Math.random() - 0.5) * 200,
    0,
    (Math.random() - 0.5) * 200
  );
  dummy.rotation.y = Math.random() * Math.PI * 2;
  dummy.scale.setScalar(0.8 + Math.random() * 0.4);
  dummy.updateMatrix();
  instancedMesh.setMatrixAt(i, dummy.matrix);
}
instancedMesh.instanceMatrix.needsUpdate = true;
scene.add(instancedMesh);

7.3 LOD（多细节层次）

对于远近距离视觉差异大的模型，在 Blender 中准备 3 个精度版本（高/中/低），Three.js 中根据距离自动切换：

const lod = new THREE.LOD();

// 高精度：0~10 米
lod.addLevel(highDetailMesh, 0);
// 中精度：10~50 米  
lod.addLevel(medDetailMesh, 10);
// 低精度：50 米以上
lod.addLevel(lowDetailMesh, 50);

scene.add(lod);
// LOD 会在每帧自动根据相机距离切换

---

八、进阶：自定义 Shader 扩展 glTF 材质

Three.js 的 onBeforeCompile 钩子允许在不放弃 PBR 管线的前提下，向材质注入自定义 GLSL 代码。这是高阶扩展的核心技巧。

// 在 Blender 中建好基础 PBR 材质，导出后：
model.traverse((node) => {
  if (node.isMesh && node.material.name === 'WindyGrass') {
    node.material.onBeforeCompile = (shader) => {
      // 注入 uniform
      shader.uniforms.uTime = { value: 0 };
      shader.uniforms.uWindStrength = { value: 0.3 };

      // 在顶点着色器头部注入声明
      shader.vertexShader = shader.vertexShader.replace(
        '#include <common>',
        `
        #include <common>
        uniform float uTime;
        uniform float uWindStrength;
        `
      );

      // 在顶点变换前注入风力位移
      shader.vertexShader = shader.vertexShader.replace(
        '#include <begin_vertex>',
        `
        #include <begin_vertex>
        // 根据 Y 轴高度决定摆动幅度（根部固定）
        float windFactor = position.y * uWindStrength;
        transformed.x += sin(uTime * 2.0 + position.z * 0.5) * windFactor;
        transformed.z += cos(uTime * 1.5 + position.x * 0.5) * windFactor * 0.5;
        `
      );

      // 保存 shader 引用以便每帧更新
      node.material.userData.shader = shader;
    };
  }
});

// 在渲染循环中更新 uniform
function animate() {
  requestAnimationFrame(animate);
  const t = clock.getElapsedTime();

  scene.traverse((node) => {
    if (node.isMesh && node.material.userData.shader) {
      node.material.userData.shader.uniforms.uTime.value = t;
    }
  });

  renderer.render(scene, camera);
}

---

九、完整工作流总结

Blender 创作阶段
│
├── 建模（控制面数，UV 展开）
├── 材质（Principled BSDF，程序化贴图）
├── 烘焙（BaseColor / Roughness / Normal / AO）
├── 动画（骨骼 / Shape Key / 物理模拟烘焙）
└── 导出（glTF 2.0 / .glb / Draco 压缩）
         │
         ▼
    glb / gltf 文件
         │
         ▼
Three.js 运行时阶段
│
├── 加载（GLTFLoader + DRACOLoader + KTX2Loader）
├── 材质增强（envMap / onBeforeCompile / 自定义 Shader）
├── 动画驱动（AnimationMixer / crossFadeTo）
├── 灯光配置（HDR 环境 + 实时灯光）
├── 性能优化（InstancedMesh / LOD / 纹理压缩）
└── 交互与后处理（Controls / EffectComposer）

---

十、推荐工具与资源

工具/资源	用途
gltf.report(gltf.report/)	分析 glTF 文件结构与优化建议
glTF Viewer(gltf-viewer.donmccurdy.com/)	快速预览 glTF/glb 文件
KTX-Software(github.com/KhronosGrou…)	纹理压缩工具
Poly Haven(polyhaven.com/)	免费 HDR / 贴图 / 3D 模型
Three.js Editor(threejs.org/editor/)	在线 Three.js 场景编辑器
glTF Transform(gltf-transform.dev/)	命令行 glTF 优化工具
Blender glTF 文档(developer.blender.org/docs)	官方导出插件文档

---

推荐大佬

• 郭隆邦：www.webgl3d.cn/
• Bruno Simon（布鲁诺·西蒙）：github.com/brunosimon

最后

Three.js 与 Blender 的结合，不是简单的"导出然后加载"，而是一套需要深度理解两个系统各自机制，并在接缝处做精细处理的工程实践。从 PBR 材质的精确映射，到动画系统的无缝对接，再到面向 Web 的性能优化，每个环节都有大量细节值得深挖。

掌握这套工作流，你将拥有从零到一打造高质量 Web 3D 体验的完整能力——既能胜任艺术侧的内容生产，也能驾驭工程侧的实时渲染。这正是当下 Web 3D 领域最稀缺的复合型能力。

现在AI还无法胜任3D可视化相关的工作，学起来为自己增加点筹码。需要相关blender、可视化学习资料的可以关注我私信获取

---

本文覆盖 Blender 4.x + Three.js r160+ 版本，部分 API 在旧版本中可能有差异

3月30日，法国人工智能初创公司Mistral AI宣布，已获得8.3亿美元的债务融资，用于在巴黎郊外建设数据中心项目。Mistral表示，这笔资金将用于从英伟达公司购买13,800个GB300芯片，用于在法国建设数据中心，该数据中心将于2026年第二季度投入运营。Mistral计划到2027年底，在欧洲各地提供200兆瓦的数据中心容量。（界面）

36氪获悉，工业富联公告，公司本次股份回购计划已达到回购金额下限，本次回购已实施完毕。本次回购实际使用资金总额5亿元，累计回购股份1410.35万股，占总股本0.07%，回购价格区间为18.40元/股至63.40元/股，均价35.45元/股。根据方案，所回购股份将全部用于注销并减少注册资本，注销日期为2026年3月31日。本次回购不会对公司日常经营、财务状况及股权分布产生重大影响，公司控制权未发生变化。

36氪获悉，碧桂园发布2025年业绩报告。报告显示，截至2025年12月31日止年度，集团实现总收入约为1548.9亿元，同比减少约38.7%；集团实现净利润约为16.2亿元，归属公司股东应占净利润约为32.6亿元。

36氪获悉，澜起科技发布2025年业绩报告。报告显示，公司2025年实现营业收入54.56亿元，同比增长49.9%；归属于上市公司股东的净利润22.36亿元，同比增长58.4%。公司2025年度利润分配预案为每10股派发现金红利3.90元(含税)，不送红股，不以公积金转增股本。

太棒了！👏
你已经从“理解 Promise”走到了“创造可用工具”的阶段。

现在，我们来手把手带你把 MyPromise 发布到 npm ——
完成一次 从学习 → 实践 → 分享 的完整闭环！

---

包名示例：@yourname/mypromise 或 mypromise-learn

功能：

import MyPromise from 'mypromise-learn';

new MyPromise(resolve => resolve('Hello')).then(console.log);

---

✅ 第一步：准备工作

1. 安装 Node.js 和 npm

确保你已安装：

node -v   # 应输出 v14.x 以上
npm -v    # 应输出 6.x 以上

👉 下载地址：nodejs.org

---

2. 注册 npm 账号（如果还没有）

访问：www.npmjs.com/signup

然后在终端登录：

npm login
# 输入你的用户名、密码、邮箱

✅ 登录成功后就可以发布包了。

---

📁 第二步：创建项目目录结构

mkdir mypromise-npm
cd mypromise-npm
npm init -y

生成的 package.json 长这样：

{
  "name": "mypromise-learn",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "keywords": ["promise", "tutorial", "async"],
  "author": "Your Name",
  "license": "MIT"
}

💡 建议名字别叫 mypromise，容易和别人冲突。可以用 mypromise-learn、simple-promise 等。

---

📄 第三步：添加源码文件

创建 index.js：

// index.js
const PENDING = 'pending';
const FULFILLED = 'fulfilled';
const REJECTED = 'rejected';

class MyPromise {
  constructor(executor) {
    this.status = PENDING;
    this.value = undefined;
    this.reason = undefined;
    this.onFulfilledCallbacks = [];
    this.onRejectedCallbacks = [];

    const resolve = (value) => {
      if (this.status === PENDING) {
        this.status = FULFILLED;
        this.value = value;
        this.onFulfilledCallbacks.forEach(fn => fn());
      }
    };

    const reject = (reason) => {
      if (this.status === PENDING) {
        this.status = REJECTED;
        this.reason = reason;
        this.onRejectedCallbacks.forEach(fn => fn());
      }
    };

    try {
      executor(resolve, reject);
    } catch (err) {
      reject(err);
    }
  }

  then(onFulfilled, onRejected) {
    onFulfilled = typeof onFulfilled === 'function' ? onFulfilled : val => val;
    onRejected = typeof onRejected === 'function' ? onRejected : err => { throw err; };

    const promise2 = new MyPromise((resolve, reject) => {
      if (this.status === FULFILLED) {
        setTimeout(() => {
          try {
            const x = onFulfilled(this.value);
            this.resolvePromise(promise2, x, resolve, reject);
          } catch (e) {
            reject(e);
          }
        }, 0);
      } else if (this.status === REJECTED) {
        setTimeout(() => {
          try {
            const x = onRejected(this.reason);
            this.resolvePromise(promise2, x, resolve, reject);
          } catch (e) {
            reject(e);
          }
        }, 0);
      } else if (this.status === PENDING) {
        this.onFulfilledCallbacks.push(() => {
          setTimeout(() => {
            try {
              const x = onFulfilled(this.value);
              this.resolvePromise(promise2, x, resolve, reject);
            } catch (e) {
              reject(e);
            }
          }, 0);
        });
        this.onRejectedCallbacks.push(() => {
          setTimeout(() => {
            try {
              const x = onRejected(this.reason);
              this.resolvePromise(promise2, x, resolve, reject);
            } catch (e) {
              reject(e);
            }
          }, 0);
        });
      }
    });

    return promise2;
  }

  resolvePromise(promise2, x, resolve, reject) {
    if (promise2 === x) {
      return reject(new TypeError('Chaining cycle detected'));
    }

    let called = false;

    if (x !== null && (typeof x === 'object' || typeof x === 'function')) {
      try {
        const then = x.then;
        if (typeof then === 'function') {
          then.call(x,
            y => {
              if (called) return;
              called = true;
              this.resolvePromise(promise2, y, resolve, reject);
            },
            r => {
              if (called) return;
              called = true;
              reject(r);
            }
          );
        } else {
          resolve(x);
        }
      } catch (e) {
        if (called) return;
        called = true;
        reject(e);
      }
    } else {
      resolve(x);
    }
  }

  catch(onRejected) {
    return this.then(null, onRejected);
  }

  static resolve(value) {
    return new MyPromise(resolve => resolve(value));
  }

  static reject(reason) {
    return new MyPromise((_, reject) => reject(reason));
  }

  static all(promises) {
    return new MyPromise((resolve, reject) => {
      const results = [];
      let count = 0;
      if (promises.length === 0) return resolve(results);
      promises.forEach((p, index) => {
        MyPromise.resolve(p).then(
          value => {
            results[index] = value;
            count++;
            if (count === promises.length) resolve(results);
          },
          reject
        );
      });
    });
  }

  static race(promises) {
    return new MyPromise((resolve, reject) => {
      promises.forEach(p => {
        MyPromise.resolve(p).then(resolve, reject);
      });
    });
  }
}

module.exports = MyPromise;

⚠️ 如果你用的是 ES6 模块语法（import/export），需要改为 export default MyPromise 并设置 "type": "module"，后面会说明。

---

🧪 第四步：本地测试一下

创建 test.js 测试文件：

// test.js
const MyPromise = require('./index');

console.log('开始测试 MyPromise...');

MyPromise.resolve(1)
  .then(res => res + 1)
  .then(res => {
    console.log('结果:', res); // 输出: 结果: 2
    return MyPromise.resolve(3);
  })
  .then(console.log) // 输出: 3
  .catch(console.error);

// 测试循环引用
const p = MyPromise.resolve(1);
const p2 = p.then(() => p2);
p2.catch(err => console.log('捕获循环引用:', err.message));

运行测试：

node test.js

✅ 如果输出正常，说明可以发布了！

---

📦 第五步：完善 package.json（关键配置）

{
  "name": "mypromise-learn",
  "version": "1.0.0",
  "description": "A hand-written Promise implementation for learning purposes.",
  "main": "index.js",
  "scripts": {
    "test": "node test.js"
  },
  "keywords": ["promise", "tutorial", "async", "javascript"],
  "author": "Your Name <you@email.com>",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "https://github.com/yourname/mypromise.git"
  },
  "bugs": {
    "url": "https://github.com/yourname/mypromise/issues"
  },
  "homepage": "https://github.com/yourname/mypromise#readme"
}

📌 注意：

• name 必须全局唯一
• 可以先查是否已被占用：www.npmjs.com/search

---

🔐 第六步：发布到 npm

npm publish

✅ 成功后你会看到：

+ mypromise-learn@1.0.0

🎉 恭喜！你的包已经上线！

访问：https://www.npmjs.com/package/mypromise-learn 查看页面。

---

🌐 第七步：别人怎么使用它？

安装：

npm install mypromise-learn

使用：

const MyPromise = require('mypromise-learn');

// 或 ES6 import（需支持 module）
import MyPromise from 'mypromise-learn';

---

🎁 进阶建议（让项目更专业）

功能	方法
📄 添加 README.md	写清楚用途、API、示例
🧩 支持 ESM	加 "type": "module" 并导出 .mjs 文件
🧪 单元测试	用 Jest 写测试用例
🔄 自动发布	用 GitHub Actions 实现 CI/CD
📘 文档站点	用 VitePress 写文档

---

❤️ 最后一句话

你已经完成了从“学习者”到“贡献者”的转变。

你现在不只是在学代码，
而是在向世界分享你的理解与创造。

这比任何面试题都更有价值。✨

---