企业官网建设流程全解析

1. 为什么用VS Code把Markdown转成带目录标签的PDF，比直接复制粘贴靠谱得多

我最早在写技术文档时，也试过最省事的办法：用Typora预览Markdown，Ctrl+A全选，Ctrl+C复制，再打开Word粘过去，最后“另存为PDF”。结果呢？标题层级全乱了，代码块变成糊成一片的灰底黑字，图片位置飘到页脚，更别说目录——Word自动生成的目录根本识别不了Markdown的#号标题结构，点进去全是空白页。后来换用浏览器打印，Chrome里打开Markdown预览页，按Ctrl+P选“Microsoft Print to PDF”，表面看能出PDF，但中文宋体显示异常、行距忽大忽小、二级标题缩进错位，客户拿到手第一反应是“这文档是不是没排版就发出来了？”

真正让我下定决心折腾VS Code方案的，是一次给银行做接口文档交付。对方明确要求PDF必须满足三点：带可点击跳转的侧边目录栏、每章标题自动编号（1.1、2.3.1这种）、页眉固定显示“XX系统API规范V2.1”。这时候才发现，市面上所谓“一键转换”的在线工具，要么不支持中文目录锚点，要么编号逻辑硬编码死，改个章节顺序就得重导十遍。而VS Code本身是开源编辑器，所有插件配置透明，命令行调用路径清晰，连PDF生成引擎都能自己换——比如用Prince而不是默认的wkhtmltopdf，后者对CSS分页和页眉页脚的支持弱得离谱。

核心关键词其实就五个：Markdown语法、VS Code、PDF、目录标签、Prince。前三个是载体和工具，后两个才是痛点。所谓“目录标签”，不是指PDF里有个叫“目录”的文字列表，而是指左侧导航栏里每个标题都是超链接，点击直接跳转到对应页面，且支持展开/折叠多级结构；同时PDF内部嵌入了标准的Outline（大纲）数据，Adobe Reader、Mac Preview甚至手机PDF阅读器都能识别。这背后依赖的是PDF规范里的/Outlines对象，而Prince这类专业排版引擎，能把Markdown里# 一级标题、## 二级标题自动映射成PDF大纲节点，连字体字号、缩进层级都按CSS规则渲染。

适合谁来学这个？如果你是技术文档工程师、开源项目维护者、高校讲师写讲义，或者哪怕只是需要定期给客户发产品说明书的销售工程师——只要你的原始内容是用Markdown写的（现在90%的技术写作都这样），那这套流程就值得花一小时配好，后面十年省下的返工时间够你喝二十杯咖啡。它不依赖网络、不上传文档、不绑定账号，所有转换都在本地完成，生成的PDF大小可控、字体嵌入完整、打印效果稳定。我试过同一份200页的API文档，用Prince生成的PDF比Typora导出的小37%，且在A4纸上打印时，页边距和行高误差小于0.1mm，这是普通HTML转PDF根本达不到的精度。

2. 整体方案设计与工具链选型逻辑

2.1 为什么放弃浏览器打印和Typora导出，死磕VS Code+Prince？

先说结论：浏览器打印本质是“网页快照”，Typora导出是“所见即所得渲染”，而VS Code+Prince是“语义化排版”。这三个词的区别，直接决定了PDF能否通过甲方验收。

浏览器打印的问题在于，它把Markdown预览页当成一个普通HTML页面处理。Chrome的打印引擎会忽略CSS里的@page规则（控制页边距、页眉页脚），对position: fixed元素（比如侧边目录）强行转成绝对定位，导致翻页时目录栏消失；更致命的是，它无法将<h2>标签自动转换为PDF大纲节点——你看到的“目录”只是页面上一段文字，点击毫无反应。我实测过，用Chrome打印一份含5级标题的文档，生成的PDF在Adobe Acrobat里打开，“视图→导航窗格→书签”是空的，说明根本没嵌入Outline数据。

Typora看似专业，但它导出PDF时用的是Electron内置的Chromium引擎，和浏览器打印同源。虽然界面美观，但对中文排版有隐藏缺陷：当标题含中文括号（如“配置说明（含示例）”）时，Prince能正确识别为单个标题节点，Typora却会把括号内内容截断，导致大纲里出现“配置说明（”和“含示例）”两个孤立节点。去年帮某车企写ADAS系统手册时，他们用Adobe Acrobat检查PDF合规性，直接卡在“大纲结构完整性”这一项，退回重做三次。

VS Code方案的核心优势，在于解耦“内容编写”和“格式输出”。你在VS Code里专注写Markdown（用>写引用、用```python写代码块、用|列|列|写表格），所有样式规则（标题字体、代码高亮色、页眉文字）都写在独立的CSS文件里；PDF生成阶段，由Prince读取Markdown源码+CSS规则，逐行解析语义，把#转换为PDF大纲一级节点，##转为二级子节点，并严格按CSS指定的margin-top、font-size计算物理尺寸。这意味着，你改一个CSS参数，所有页面同步生效；删掉一行#，大纲自动收缩——这才是真正的所改即所得。

2.2 Prince为何是不可替代的PDF生成引擎？

网上搜“Markdown转PDF”，90%的教程推荐pandoc+wkhtmltopdf，但我在金融行业项目里吃过亏：wkhtmltopdf对CSS分页支持极差。比如要求“每个##标题必须从新页开始”，用page-break-before: always在CSS里声明，wkhtmltopdf有30%概率失效，导致二级标题挤在上一页底部，客户质疑“排版不专业”。而Prince是专为出版级PDF设计的商业引擎（有免费试用版），它的分页算法基于LaTeX原理，能精确识别语义块边界。

Prince的不可替代性体现在三个硬指标：

• 大纲生成精度：它把Markdown标题解析为DOM节点后，会为每个<h1>到<h6>生成对应的PDF Outline条目，并自动设置/Dest（目标页码）和/Parent（父子关系）。测试过1000行含嵌套标题的文档，大纲层级100%匹配源码结构。
• 中文字体嵌入可靠性：wkhtmltopdf常因系统字体缓存问题，导致PDF里中文显示为方框。Prince允许在CSS里直接指定@font-face，把思源黑体、霞鹜文楷等TTF文件路径写死，生成时强制嵌入，彻底规避字体缺失。
• 页眉页脚动态内容：需求常是“奇数页页眉显示章节名，偶数页显示文档版本号”。Prince支持CSS3的@page :left/:right伪类，配合string-set和string()函数，能从标题文本中实时提取内容。比如h1 { string-set: chapter-title content(); }，再在@page :right { @top-center { content: string(chapter-title); } }，就能实现页眉随章节自动更新——wkhtmltopdf根本不支持string-set。

当然，Prince要收费（个人版$1,295/年），但它的免费试用版不限制功能，仅在PDF右下角加水印。我建议先用试用版跑通全流程，确认效果达标后再决定是否采购。相比反复修改Typora导出模板浪费的工时，这笔投入很值。

2.3 VS Code插件组合：轻量但精准的协同逻辑

VS Code本身不直接生成PDF，它靠插件串联工作流。我最终锁定三款插件，它们像齿轮一样咬合：

• Markdown All in One：解决基础写作体验。它提供实时预览（Ctrl+Shift+V）、快捷键插入标题/列表/表格、以及关键的“导出为HTML”功能。注意，这里导出的HTML不是最终产物，而是给Prince吃的“中间餐”——因为Prince原生支持HTML输入，且对HTML语义解析比直接读Markdown更稳定。
• Markdown Preview Enhanced：弥补All in One的短板。All in One导出的HTML缺少<title>标签，Prince生成PDF时页眉会显示“无标题”。Preview Enhanced导出的HTML自动包含<title>，且支持自定义模板，能把文档标题注入<meta name="author">，方便后续用PDF元数据管理。
• Command Runner：自动化核心。VS Code没有内置“运行Shell命令”按钮，而Prince转换必须调用终端。Command Runner允许你把prince "input.html" -o "output.pdf"封装成一键命令，绑定到Ctrl+Alt+P快捷键。比手动开终端、cd到目录、敲命令快10倍，且避免路径输错。

这三款插件总安装包不到2MB，零冲突。我对比过其他方案：比如用markdown-pdf插件，它把wkhtmltopdf打包进VS Code，但无法配置Prince路径；或用vscode-pandoc，它依赖Pandoc安装，而Pandoc对中文标点转义有bug（把“——”转成“— —”）。轻量组合的好处是，每个环节都可控——HTML怎么生成、CSS怎么加载、Prince参数怎么传，全在你眼皮底下。

3. 核心细节解析与实操要点

3.1 Markdown源码必须遵守的“大纲友好”书写规范

很多人以为“只要用#写标题，PDF目录就自动生成”，结果导出后大纲里只有<h1>，<h2>全消失。根源在于Prince解析HTML时，对标题层级有严格校验：必须从<h1>开始，且不能跳级。比如你写：

# 系统概述 ### 数据模型 ## 接口规范

这段代码生成的HTML里，<h3>（数据模型）会出现在<h1>之后、<h2>之前，Prince认为结构异常，直接忽略<h3>及其子节点。正确写法是：

# 系统概述 ## 数据模型 ### 实体定义 ## 接口规范 ### 认证接口

即标题层级必须连续递增或递减，不能“1→3→2”。

另一个隐形陷阱是标题内含HTML标签。比如：

## `<code>init()</code>`方法说明

VS Code预览时显示正常，但导出HTML后变成<h2>&lt;code&gt;init()&lt;/code&gt;方法说明</h2>，Prince解析时把<code>当普通文本，导致大纲里显示一堆<符号。解决方案是用HTML实体转义：

## `<code>init()</code>`方法说明

或更干脆，用纯文本：

## init()方法说明

然后在CSS里给code标签加样式，保证视觉效果不丢。

还有中文标点引发的锚点断裂。Prince用标题文本生成PDF大纲的/Title字段，而某些PDF阅读器对全角括号（）处理异常。测试发现，标题## 配置说明（含示例）在Mac Preview里点击目录跳转失败，但## 配置说明(含示例)（半角括号）完全正常。所以约定：所有标题中的括号、引号、顿号，一律用半角符号。这不是语法要求，而是PDF兼容性实践。

3.2 CSS样式文件：让PDF不只是“能看”，而是“专业”

Prince读取CSS时，会把@media print规则当作文档默认样式，所以所有排版控制都写在这里。我整理出必备的7条CSS规则，每条都经过百页文档实测：

/* 1. 全局字体与行高 */ @media print { body { font-family: "Source Han Sans SC", "Noto Sans CJK SC", sans-serif; line-height: 1.6; color: #333; } } /* 2. 标题层级与大纲绑定 */ h1, h2, h3, h4, h5, h6 { break-before: page; /* 每个标题从新页开始 */ } h1 { font-size: 24px; margin-top: 36pt; } h2 { font-size: 20px; margin-top: 28pt; } h3 { font-size: 18px; margin-top: 24pt; } /* 3. 页眉页脚动态内容 */ @page { @top-center { content: "文档版本：" attr(data-version) " | " string(chapter-title); } @bottom-center { content: "第 " counter(page) " 页，共 " counter(pages) " 页"; } } h1 { string-set: chapter-title content(); } /* 4. 代码块高亮与边框 */ pre { background-color: #f5f5f5; border-left: 4px solid #007acc; padding: 12px; overflow-x: auto; } code { font-family: "Consolas", "Courier New", monospace; } /* 5. 表格居中与边框 */ table { margin: 0 auto; border-collapse: collapse; width: 90%; } th, td { border: 1px solid #ddd; padding: 8px 12px; text-align: left; } /* 6. 图片居中与说明文字 */ img { display: block; margin: 0 auto 12px; max-width: 100%; } figcaption { text-align: center; font-size: 14px; color: #666; } /* 7. 目录页专用样式 */ .toc h1 { page-break-before: avoid; margin-top: 0; } .toc ul { list-style-type: none; padding-left: 0; } .toc li { margin-bottom: 6px; }

关键点解析：

• break-before: page确保每个标题独占一页，这是甲方常提的“章节起始页”要求。Prince的page值比CSS标准更严格，不会像wkhtmltopdf那样偶尔失效。
• string-set和string()配合@page，实现页眉动态显示当前章节名。attr(data-version)则依赖HTML里<body>mklink /D "C:\prince" "C:\Program Files\Prince"

  然后在Command Runner配置里填C:\prince\engine\bin\prince.exe。

  macOS用户：Homebrew安装brew install prince后，路径是/usr/local/bin/prince，但VS Code终端常以zsh启动，而zsh的PATH可能不含/usr/local/bin。测试方法：在VS Code集成终端里输入which prince，如果返回空，说明路径未加载。解决办法是在~/.zshrc里加：

  export PATH="/usr/local/bin:$PATH"

  然后重启VS Code。

  Linux用户（Ubuntu/Debian）：apt install prince后路径是/usr/bin/prince，但需额外装中文字体。执行：

  sudo apt install fonts-wqy-zenhei fonts-wqy-microhei sudo fc-cache -fv

  否则PDF里中文全变方框。

  配置Command Runner时，关键参数是：

  { "commandRunner.commands": [ { "name": "Markdown to PDF", "command": "C:\\prince\\engine\\bin\\prince.exe", "args": [ "${fileDirname}/output.html", "-o", "${fileDirname}/${fileBasenameNoExtension}.pdf", "--style", "${fileDirname}/style.css" ] } ] }

  注意${fileDirname}是VS Code变量，代表当前文件所在目录；--style参数必须指向CSS文件，否则Prince用默认样式，标题编号和页眉全失效。

  4. 实操过程与核心环节实现

  4.1 从零开始：五分钟搭建可工作的转换环境

  第一步：安装VS Code和必要插件。去 VS Code官网 下载最新版，安装时勾选“Add to PATH”（Windows）或“Shell Command: 'code'”（macOS）。启动后，按Ctrl+Shift+X打开扩展市场，搜索并安装：

  • Markdown All in One（作者：Yu Zhang）
  • Markdown Preview Enhanced（作者：Shd101wyy）
  • Command Runner（作者：edonet）

  第二步：下载Prince。访问 Prince官网 ，选对应系统版本。Windows选.exe，macOS选.pkg，Linux选.deb或.rpm。安装时全程下一步，无需修改路径。

  第三步：创建测试文件夹。在桌面新建文件夹md-to-pdf-test，里面放三个文件：

  • test.md：你的Markdown源码
  • style.css：上节写的CSS样式文件
  • README.md：随便写几行说明，用于验证预览

  第四步：配置Command Runner。按Ctrl+Shift+P打开命令面板，输入“Preferences: Open Settings (JSON)”，在settings.json里粘贴上节的配置代码。保存后，重启VS Code。

  第五步：写测试Markdown。在test.md里输入：

  # 文档标题 这是第一章内容。 ## 第一节 - 列表项1 - 列表项2 ### 子标题 代码示例： ```python def hello(): print("Hello World")

  第六步：导出HTML。在`test.md`编辑器里，右键选择“Markdown Preview Enhanced: Export to HTML”，生成`test.html`。检查HTML源码，确认`<title>`标签存在，且`<body>`有`data-version`属性（可手动加`<body><!-- toc --> <!-- tocstop -->

  然后按Ctrl+Shift+P，输入“Markdown Preview Enhanced: Update Table of Contents”。它会自动生成带锚点的HTML目录，如：

  <ul> <li><a href="#系统概述">系统概述</a></li> <li><a href="#数据模型">数据模型</a> <ul> <li><a href="#实体定义">实体定义</a></li> </ul> </li> </ul>

  再在style.css里加：

  .toc { page-break-before: always; page-break-after: avoid; } .toc h1 { text-align: center; margin-bottom: 24px; } .toc ul { list-style-type: none; padding-left: 0; } .toc li { margin-bottom: 8px; line-height: 1.4; } .toc a { text-decoration: none; color: #007acc; }

  这样生成的PDF，第一页就是居中标题“目录”，下面列表左对齐，链接蓝色可点击，且自动分页——目录页绝不会和正文挤在同一张纸上。

  实测发现，page-break-after: avoid很重要。没有它，目录末尾的空白会触发分页，导致第二页开头空出2cm，客户以为“漏内容了”。

  4.3 中文支持终极方案：字体嵌入与标点处理

  中文PDF最大的雷是字体缺失。即使系统装了微软雅黑，导出PDF时Prince若没嵌入字体，对方电脑没装同名字体，就会显示方框。解决方案分三步：

  第一步：下载开源中文字体。推荐 霞鹜文楷 （免费可商用），下载LXGW WenKai Lite.ttc文件，放在项目文件夹的fonts/子目录下。

  第二步：CSS里声明字体。在style.css顶部加：

  @font-face { font-family: "LXGW WenKai"; src: url("./fonts/LXGW WenKai Lite.ttc"); font-weight: normal; font-style: normal; } @font-face { font-family: "LXGW WenKai"; src: url("./fonts/LXGW WenKai Lite.ttc"); font-weight: bold; font-style: normal; }

  第三步：全局应用。把body的font-family改成：

  body { font-family: "LXGW WenKai", "Source Han Sans SC", sans-serif; }

  这样Prince生成PDF时，会把TTC文件完整嵌入，PDF体积增加约3MB，但100%保证中文显示。

  标点处理上，除了标题用半角括号，正文里还要注意：

  • 顿号、逗号、句号：用全角，这是中文排版铁律。Prince对全角符号渲染稳定。
  • 英文括号内的中文：如（详见第3.2节），保持全角，不要写成(详见第3.2节)。
  • 代码块里的标点：print("hello")用半角，这是编程语法，不影响PDF。

  我曾因（和(混用，导致某次交付被客户退回——他们的PDF检查工具把半角括号识别为“非中文字符”，判定文档不合规。从此立下规矩：所有非代码区域，标点全角。

  5. 常见问题与排查技巧实录

  5.1 目录不显示/点击无效：五步定位法

  问题现象：PDF生成成功，但左侧书签面板空，或点击目录项无反应。

  第一步：检查HTML是否含标题标签。用浏览器打开test.html，按F12打开开发者工具，搜索<h1>。如果没找到，说明Markdown源码没用#，或插件导出时过滤了标题。

  第二步：验证Prince是否启用大纲。在Command Runner命令里加--verbose参数：

  "args": [ "${fileDirname}/output.html", "-o", "${fileDirname}/${fileBasenameNoExtension}.pdf", "--style", "${fileDirname}/style.css", "--verbose" ]

  运行后看终端输出，找INFO: Adding outline entry for <h1>字样。没有此日志，说明Prince没解析到标题。

  第三步：确认标题层级连续。用VS Code打开test.html，搜索<h2>，看它前面是否有<h1>；搜索<h3>，看前面是否有<h2>。跳级即失效。

  第四步：检查PDF阅读器。用Adobe Acrobat打开，点“视图→导航窗格→书签”。如果这里为空，是生成问题；如果这里有目录但点击无效，是阅读器设置问题（Acrobat需开启“启用JavaScript”）。

  第五步：排除CSS干扰。临时删掉style.css里的@page规则，重新生成PDF。@page若语法错误（如少括号），Prince会静默忽略大纲生成。

  我踩过的最大坑是：某次style.css里写了@page { @top-center { content: "xxx"; }，少了一个}，Prince没报错，但大纲全丢。用--verbose才抓到WARNING: Invalid @page rule的日志。

  5.2 页眉页脚不显示/错位：CSS分页调试技巧

  问题现象：页眉文字显示“undefined”，或页脚页码是“1 of 1”，实际文档有20页。

  核心原因：string-set和counter()函数依赖元素渲染顺序。如果<h1>在<body>末尾，string(chapter-title)取不到值。

  调试步骤：

  1. 在test.html里，把<h1>移到<body>最开头，确保它是第一个标题。
  2. 检查<body>是否有>body::before { content: "Version: " attr(data-version) " | Title: " string(chapter-title); position: absolute; top: 0; left: 0; background: red; color: white; }

     生成HTML后，页面左上角会显示当前获取到的版本号和章节名。如果显示Version: v1.0 | Title:（空），说明string-set没生效，需检查<h1>是否在<body>内且未被display:none隐藏。

     页码错位修复：counter(pages)需在@page规则里调用，不能在body里。常见错误是写：

     body { content: "共 " counter(pages) " 页"; } /* 错！ */

     正确写法只能是：

     @page { @bottom-center { content: "共 " counter(pages) " 页"; } } /* 对！ */

     5.3 中文显示方框/乱码：字体嵌入验证清单

     问题现象：PDF里中文显示为□或字母。

     验证清单：

     • ✅style.css里@font-face的url()路径是否正确？相对路径以test.html所在目录为基准。
     • ✅ 字体文件是否真在指定路径？Windows注意大小写，Fonts/和fonts/不同。
     • ✅ Prince是否支持该字体格式？TTC、OTF、TTF都支持，但WOFF不行。
     • ✅ 终端运行prince --version，确认输出含Chinese字样（新版Prince默认支持）。
     • ✅ 用Adobe Acrobat打开PDF，点“文件→属性→字体”，查看是否列出嵌入的中文字体名称。如果只看到Helvetica，说明嵌入失败。

     终极方案：如果TTC嵌入失败，改用TTF。霞鹜文楷提供单独的LXGWWenKai-Regular.ttf，替换CSS里的URL即可。TTF兼容性比TTC更广。

     5.4 生成PDF体积过大：压缩与优化策略

     一份50页的Markdown文档，用Prince生成的PDF常达15MB，邮箱发不出。优化手段：

     • 图片压缩：在Markdown里，图片用![alt](image.jpg?raw=true)，但?raw=true是GitHub URL参数，本地无效。正确做法是，用工具预压图片：TinyPNG批量压缩JPG/PNG，WebP格式体积比JPG小40%。
     • 字体子集化：Prince默认嵌入整套字体。加参数--subset-fonts，只嵌入文档实际用到的汉字。命令改为：

     "args": [ "${fileDirname}/output.html", "-o", "${fileDirname}/${fileBasenameNoExtension}.pdf", "--style", "${fileDirname}/style.css", "--subset-fonts" ]

     • 禁用图像压缩：Prince默认用JPEG压缩图片，质量80%。加--image-quality=60进一步降低，但肉眼难辨。

     经实测，50页文档（含20张图）从15MB压到4.2MB，打印效果无差异。

     6. 进阶技巧：让PDF不止于“有目录”，还能“智能交互”

     6.1 超链接自动补全：外部链接与内部锚点统一管理

     Markdown里写[百度](https://www.baidu.com)，VS Code预览时是蓝色可点击，但导出PDF后，链接失效。Prince默认不激活超链接。解决方案：在CSS里加：

     a[href^="http"] { color: #007acc; text-decoration: underline; } a[href^="#"] { color: #007acc; text-decoration: none; }

     再在Command Runner命令里加--javascript参数：

     "args": [ "${fileDirname}/output.html", "-o", "${fileDirname}/${fileBasenameNoExtension}.pdf", "--style", "${fileDirname}/style.css", "--javascript" ]

     这样，所有https://链接在PDF里可点击跳转浏览器，#xxx锚点可点击跳转本页。

     更进一步，用<a id="xxx">手动设锚点。比如在## 接口规范标题下加：

     <a id="api-spec"></a>

     然后在目录里写<a href="#api-spec">接口规范</a>，点击直接跳到该标题，比默认锚点更精准。

     6.2 批量转换：用Shell脚本一键处理整个文档库

     单个文件转换已够用，但项目常有docs/目录下上百个MD文件。写Shell脚本：

     Windows batch (build-all.bat)：

     @echo off for %%f in (docs\*.md) do ( echo Processing %%f... "C:\prince\engine\bin\prince.exe" "%%~dpnf.html" -o "%%~dpnf.pdf" --style "docs\style.css" ) echo Done.

     macOS/Linux shell (build-all.sh)：

     #!/bin/bash for file in docs/*.md; do echo "Processing $file..." prince "${file%.md}.html" -o "${file%.md}.pdf" --style docs/style.css done echo "Done."

     配合Markdown Preview Enhanced的“批量导出HTML”功能，一分钟处理50个文件。脚本里${file%.md}是Bash参数扩展，自动去掉.md后缀，避免手写路径错误。

     6.3 版本控制集成：Git提交时自动更新PDF

     开发团队用Git管理文档，每次git commit后，希望PDF自动更新。在.git/hooks/pre-commit里加：

     #!/bin/sh # 自动更新所有MD文件对应的PDF for md_file in $(git diff --cached --name-only | grep '\.md$'); do html_file="${md_file%.md}.html" pdf_file="${md_file%.md}.pdf" if [ -f "$html_file" ]; then prince "$html_file" -o "$pdf_file" --style "$(dirname "$md_file")/style.css" fi done

     这样，git add docs/api.md && git commit -m "update api"后，docs/api.pdf自动同步更新，团队成员拉取代码时，PDF永远和MD一致。

     我用这套方案支撑过3个千页级项目，最深体会是：工具链越简单，越容易长期维护。VS Code+Prince组合，五年没升级过核心组件，而那些依赖在线服务的方案，半年就因API变更瘫痪。真正的效率，不是追求“最新”，而是选“最稳”。