1. 从“e2e”说起：端到端测试到底在测什么

第一次看到“e2e”这个词，很多人会以为是某个新框架的缩写，或者某个内部项目的代号。其实它就是end-to-end的缩写，中文叫“端到端”。在软件研发语境里，e2e 通常指端到端测试——从用户真实操作的入口开始，一路走到系统最末端，验证整条链路上每个环节是否都能正常协作。它不关心某个函数写得漂不漂亮，也不关心某个接口的单元测试覆盖率有多高，它只关心一件事：用户能不能把这件事完整地做完。

我做了十多年一线研发和测试，见过太多团队在单元测试上刷到 90% 覆盖率，结果一上线用户连登录都登不进去。原因很简单，单元测试是“零件合格证”，e2e 测试才是“整车路试”。零件都合格，装到一起未必能跑，这就是 e2e 存在的意义。它解决的是集成后的真实行为验证问题，适合所有需要交付可用产品的研发团队，无论你是做 Web、App、小程序还是桌面端，只要存在“用户操作链路”，e2e 就有用武之地。

而最近热词里出现的“e2e profile1”，则把话题引向了更具体的层面——e2e 的配置档案（profile）。在很多 e2e 工具链里，profile 是一组环境、参数、浏览器、账号、数据准备的集合。你可以把它理解成“一套预设的测试场景套餐”：profile1 可能代表“本地开发环境 + Chrome + 测试账号”，profile2 代表“预发环境 + 无头模式 + 影子库”。热词的出现说明大家已经不满足于“能不能跑 e2e”，而是开始关心“怎么把 e2e 跑得可管理、可切换、可复现”。这篇文章就围绕 e2e 的核心逻辑、profile 的设计思路、实操落地和踩坑经验，完整讲一遍。

2. e2e 测试的整体设计与方案选型

2.1 为什么 e2e 不能替代单元测试和集成测试

很多刚接触测试金字塔的人会有一个误区：既然 e2e 最接近真实用户，那是不是只写 e2e 就够了？我实测下来的结论是：只写 e2e 的团队，最后都会被维护成本拖垮。原因有三点。第一，e2e 执行慢，一个完整链路动辄几十秒到几分钟，单元测试毫秒级就能跑完，两者数量级差了几百倍。第二，e2e 脆弱，页面改个按钮文案、接口返回字段顺序变一下，都可能让用例挂掉，而单元测试只依赖函数契约。第三，e2e 定位问题难，一个用例失败，可能是前端渲染、网络、后端逻辑、数据库、第三方服务任意一环出问题，排查成本远高于单元测试。

所以正确的设计思路是分层：单元测试保证零件正确，集成测试保证模块间接口正确，e2e 保证用户链路正确。e2e 的数量应该少而精，只覆盖核心业务路径，比如登录、下单、支付、退款、核心配置保存。那些边界条件、异常分支，尽量下沉到单元和集成层去测。这样 e2e 用例数量控制在几十条以内，执行时间可控，维护成本也能接受。

2.2 e2e 工具选型的几个关键考量

选 e2e 工具，我一般看四个维度：跨浏览器能力、等待机制、调试体验、生态成熟度。早期大家用 Selenium，优点是浏览器支持最全，缺点是 API 偏底层，等待要自己写，调试靠截图，写起来很累。后来 Puppeteer 出来了，Chrome 生态里非常顺手，但它主要面向 Chrome，跨浏览器是短板。再往后 Playwright 和 Cypress 成为主流选择。

Cypress 的优势是开发者体验极好，自带时间旅行调试、自动等待、实时重载，写起来像写前端单测。但它的架构决定了它跑在浏览器内，多标签页、多域名场景支持有限，而且早期只支持 Chrome 系。Playwright 则是微软出品，支持 Chromium、Firefox、WebKit 三大内核，多标签、多上下文、网络拦截、移动端模拟都很强，自动等待也做得不错，近两年在团队里用得越来越多。

我的建议是：如果你的产品是内部后台、单域名为主、团队前端经验强，Cypress 上手最快；如果产品面向多端、多浏览器、有复杂多窗口场景，Playwright 更稳。至于 profile 的设计，两者都支持通过配置文件或环境变量切换，后面会详细讲。

2.3 e2e profile 的设计哲学：一套代码，多套环境

“e2e profile1”这个热词背后，其实是一个很实际的工程问题：同一套 e2e 用例，怎么在本地、CI、预发、生产回归等不同环境里跑，而不用改代码。答案就是 profile。profile 本质上是一组配置的命名集合，通常包含：

• baseUrl：被测系统的入口地址
• 浏览器类型与启动参数：Chrome、Firefox、无头模式、视口大小
• 测试账号与密码：不同环境账号不同
• 数据准备策略：是连真实测试库，还是用 mock，还是走接口造数
• 超时与重试策略：本地可以短超时快速失败，CI 上适当放宽
• 报告与截图策略：本地只输出控制台，CI 上生成 HTML 报告和失败截图

设计 profile 的核心原则是：用例代码只关心“做什么”，profile 关心“在哪做、用什么做”。这样新增一个环境，只需要加一个 profile 文件，而不是去改几十个用例。这也是为什么热词是“e2e profile1”而不是“e2e 测试”——大家已经过了写用例的阶段，进入了工程化管理阶段。

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

3.1 用例设计：一条 e2e 用例应该长什么样

我见过很多 e2e 用例写得像操作手册，从打开首页开始，点遍所有菜单，最后才到目标页面。这种写法有两个问题：一是执行慢，二是失败时不知道是哪一步的问题。好的 e2e 用例应该只覆盖一条核心业务路径，并且每一步都有明确的断言。

举个例子，一个“用户下单”的 e2e 用例，合理的结构是：

1. 通过接口或 storage 注入登录态，直接进入商品详情页（跳过登录 UI 操作，除非登录本身就是被测对象）
2. 选择规格，点击加入购物车
3. 进入购物车，断言商品数量、价格正确
4. 点击结算，填写收货信息
5. 提交订单，断言订单号生成、状态为“待支付”
6. 清理测试数据

注意第 1 步，能用接口准备的状态，就不要用 UI 操作去准备。UI 操作慢且不稳定，登录这种前置条件，用接口拿 token 注入是最稳的。这就是 e2e 设计里的“捷径原则”：只测你要测的那条路径，其他都用最快的方式准备好。

3.2 等待机制：e2e 失败的头号元凶

e2e 用例失败，十有八九是等待没处理好。页面还没渲染完就点击，接口还没返回就断言，元素被遮挡就操作，这些都是典型问题。早期 Selenium 时代，大家用sleep(3000)硬等，结果就是用例又慢又不稳。现代工具都提供了自动等待，但自动等待不是万能的，你需要理解它的边界。

Playwright 的自动等待会检查元素是否可见、是否可交互、是否稳定，但它不会等你业务接口返回。比如你点击“提交”后，按钮变成 loading，接口 2 秒后才返回成功提示，这时候如果你直接断言成功文案，就会失败。正确做法是显式等待业务信号，比如等待某个网络请求完成，或者等待某个特定元素出现。

// 等待接口返回后再断言，而不是等固定时间 await page.waitForResponse(resp => resp.url().includes('/api/order/create') && resp.status() === 200 ); await expect(page.locator('.order-success')).toBeVisible();

注意：绝对不要在 e2e 用例里写固定 sleep。固定 sleep 要么太短导致偶发失败，要么太长拖慢整个套件。用“等待条件”代替“等待时间”，是用例稳定的第一原则。

3.3 选择器策略：怎么让用例不因 UI 改版而崩

选择器是 e2e 用例和页面之间的契约。用 CSS class 做选择器，前端一改样式就挂；用 XPath 做选择器，结构一调整就挂。最稳的做法是和前端约定测试专用属性，比如><button>await page.click('[data-testid="submit-order"]');

如果团队暂时无法推行>const uniqueSku = `TEST-SKU-${Date.now()}`; // 用这个唯一 SKU 造商品、下单、断言、清理

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

4.1 从零搭建一套带 profile 的 e2e 工程

假设我们用 Playwright 搭建，目录结构我一般这样组织：

e2e/ ├── config/ │ ├── profile.local.ts │ ├── profile.ci.ts │ └── profile.staging.ts ├── fixtures/ │ └── auth.fixture.ts ├── tests/ │ ├── order.spec.ts │ └── login.spec.ts ├── utils/ │ ├── api.ts │ └── data.ts └── playwright.config.ts

profile 文件里放环境相关配置：

// config/profile.staging.ts export const stagingProfile = { baseUrl: 'https://staging.example.com', browser: 'chromium', headless: true, timeout: 30000, retries: 2, account: { user: 'e2e_user_staging', password: process.env.E2E_STAGING_PWD, }, };

主配置根据环境变量加载对应 profile：

// playwright.config.ts import { defineConfig } from '@playwright/test'; import { localProfile } from './config/profile.local'; import { ciProfile } from './config/profile.ci'; import { stagingProfile } from './config/profile.staging'; const profiles = { local: localProfile, ci: ciProfile, staging: stagingProfile, }; const active = profiles[process.env.E2E_PROFILE || 'local']; export default defineConfig({ use: { baseURL: active.baseUrl, headless: active.headless, }, timeout: active.timeout, retries: active.retries, });

这样跑的时候只需要：

E2E_PROFILE=staging npx playwright test

一套用例，三个环境，零代码改动。这就是 profile 的价值。

4.2 登录态复用：让每条用例都跳过登录 UI

登录是 e2e 里最浪费时间的操作。如果每条用例都走一遍登录 UI，几十条用例就是几十次登录，既慢又容易因为验证码、风控而失败。正确做法是全局登录一次，保存 storage state，后续用例复用。

Playwright 提供了storageState机制：

// global-setup.ts import { chromium } from '@playwright/test'; async function globalSetup() { const browser = await chromium.launch(); const page = await browser.newPage(); await page.goto(`${process.env.BASE_URL}/login`); await page.fill('[data-testid="username"]', process.env.E2E_USER); await page.fill('[data-testid="password"]', process.env.E2E_PWD); await page.click('[data-testid="login-submit"]'); await page.waitForURL('**/dashboard'); await page.context().storageState({ path: 'e2e/.auth/user.json' }); await browser.close(); } export default globalSetup;

然后在配置里引用：

use: { storageState: 'e2e/.auth/user.json', }

这样每条用例启动时就已经是登录态，直接进入业务页面。实测下来，整个套件能省掉 30% 到 50% 的执行时间。注意 storage state 有有效期，如果 token 过期时间短，需要在 global setup 里判断并重新登录，或者把 setup 做成可重复执行的。

4.3 网络拦截与 mock：让 e2e 不依赖不稳定的第三方

e2e 跑在真实环境，最怕第三方服务不稳定。比如支付回调、短信验证码、地图接口，这些外部依赖一旦抖动，用例就挂，但问题不在你的系统。这时候可以用网络拦截，把第三方请求 mock 掉，只保留你自己系统的真实链路。

await page.route('**/api/sms/send', route => { route.fulfill({ status: 200, body: JSON.stringify({ code: 0, msg: 'ok' }), }); });

这样短信接口不会真的发短信，但你的前端逻辑、后端校验、后续流程都是真实的。注意 mock 的粒度要控制好，只 mock 你无法控制的外部依赖，不要 mock 自己的核心接口，否则 e2e 就退化成集成测试了。

4.4 CI 集成：让 e2e 成为合并前的守门员

e2e 如果只在本地跑，价值会大打折扣。真正发挥价值是在 CI 里，每次合并请求都自动跑一遍核心用例。CI 集成的关键点有三个：并行执行、失败重试、报告归档。

并行执行是把用例分片，多个 CI 节点同时跑，缩短总时长。Playwright 支持--shard参数：

npx playwright test --shard=1/4 npx playwright test --shard=2/4

失败重试是应对偶发不稳定，配置retries: 2，第一次失败自动重试，重试通过则标记为 flaky 而不是 failed。报告归档是把 HTML 报告、失败截图、trace 文件上传到 CI 产物里，方便排查。

# CI 配置片段 - name: Run e2e run: E2E_PROFILE=ci npx playwright test --shard=${{ matrix.shard }}/4 - name: Upload report if: always() uses: actions/upload-artifact@v3 with: name: e2e-report path: e2e/report/

提示：CI 上的 e2e 不要跑全量，只跑核心冒烟用例，控制在 10 分钟以内。全量 e2e 可以放在 nightly 定时任务里跑，避免拖慢每次合并。

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

5.1 e2e 用例偶发失败，怎么定位

偶发失败是 e2e 最头疼的问题。我的排查顺序是：先看截图和 trace，再看网络请求，最后看时间线。Playwright 的 trace 功能非常强，开启后可以回放整个用例执行过程，包括每一步的 DOM 快照、网络请求、控制台日志。

use: { trace: 'on-first-retry', screenshot: 'only-on-failure', video: 'retain-on-failure', }

配置成第一次重试时开启 trace，这样正常通过的用例不产生额外开销，失败的用例有完整现场。排查时重点看：失败那一刻页面长什么样、有没有 loading、有没有报错弹窗、网络请求是否返回了预期状态。

5.2 常见问题速查表

问题现象	可能原因	排查方向	解决思路
元素找不到	页面未加载完 / 选择器变了	看截图确认页面状态	加显式等待 / 改用>test('下单成功 @smoke @order', async ({ page }) => { // ... }); npx playwright test --grep @smoke 这套组合拳打下来，e2e 才能真正成为研发流程里的守门员，而不是一个摆设。我个人在实际操作中的体会是，e2e 的价值不在于用例多，而在于核心链路始终有人守、始终能跑通。哪怕只有二十条用例，只要它们稳定、快速、每次合并都跑，就比五百条没人维护的用例有价值得多。 SEO优化 网站运营 关键词排名 推广干货 返回列表 RELATED READING 延伸阅读 更多一线实战笔记与深度复盘，助您持续精进 e2e profile1端到端测试配置详解：从原理到实操落地 1. 从“e2e”这个词说起：它到底指什么第一次看到“e2e”这三个字符，很多人会愣一下。它既不像某个具体产品的名字，也不像某个技术框架的缩写那么直观。但如果你在软件研发、测试、或者产品交付的圈子里待过一阵子，就会知道这个词出… 2026/10/27 14:16:58 阅读全文 → MySQL增量变更实时同步到Kafka：Flink CDC全链路实战与避坑指南 数据同步这件事，做过一次就再也回不去了。尤其是当业务方甩过来一句“把订单库的变更实时推到消息队列，下游好几个系统等着消费”，你脑子里第一反应大概率是写个定时任务轮询——然后立刻被自己否掉，因为轮询的延迟、对源库的压力… 2026/10/27 14:16:58 阅读全文 → hyperframes关键帧：决定全景视频画质上限的核心技术 做全景视频这行有个很有意思的现象：客户对成片的要求经常是一句话——“要那种能让人身临其境的感觉”，但当你把成片交过去，他反复回看、真正停下来细看的，往往是某一帧画面。这一帧，我们叫它 hyperframe，翻… 2026/10/27 14:16:58 阅读全文 → PIM-SM 组播分析题：IGMP、RP、RPT/SPT 与静态加组边界 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → 图解常见匹配算法 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → 100 台路由器如何选 IGP：OSPF 与 IS-IS 的分析题决策闭环 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → OSPF 多区域规划题：用 Totally Stub 区隔离服务器区路由波动 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → 在windows下libwebp库 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → 汽车传感器与执行器：从信号链到闭环控制的工程实践 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:14:48 阅读全文 → PIM-SM 组播分析题：IGMP、RP、RPT/SPT 与静态加组边界 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → 图解常见匹配算法 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → 100 台路由器如何选 IGP：OSPF 与 IS-IS 的分析题决策闭环 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → OSPF 多区域规划题：用 Totally Stub 区隔离服务器区路由波动 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → 在windows下libwebp库 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:16:48 阅读全文 → 汽车传感器与执行器：从信号链到闭环控制的工程实践 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 18:14:48 阅读全文 → 全国计算机二级C语言真题PDF高效刷题指南 简介：这份PDF是全国计算机二级C语言考试的试题与答案解析，专为备考二级C语言的考生准备。内容涵盖C语言特点与设计理念、程序基本组成单位、main函数执行流程、函数嵌套调用规则、标识符命名规范、整型实型字符型数据类型、八进制十六进制数合法形式、运… 2026/10/27 0:47:36 阅读全文 → requests+BeautifulSoup：爬虫抓取h1标题的入门实战指南 简介：一份以实战为导向的Python爬虫入门资源，面向具备基本编程基础、希望快速掌握网络数据抓取的初学者，可解决从零编写简单爬虫的常见困惑。实例以requests库发送HTTP请求、BeautifulSoup解析HTML文档，完整演示从网页中提取 标题… 2026/10/27 0:47:36 阅读全文 → OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析 简介：这是一份面向图形学求职者与3D开发者的OpenGL面试题资料，围绕计算机图形学核心考点整理，适合准备图形渲染、游戏引擎方向面试的中高级开发者查漏补缺。压缩包内共1个doc文档，约19KB，内容以问答形式覆盖渲染对象矩… 2026/10/27 0:47:36 阅读全文 → 全国计算机二级C语言真题PDF高效刷题指南 简介：这份PDF是全国计算机二级C语言考试的试题与答案解析，专为备考二级C语言的考生准备。内容涵盖C语言特点与设计理念、程序基本组成单位、main函数执行流程、函数嵌套调用规则、标识符命名规范、整型实型字符型数据类型、八进制十六进制数合法形式、运… 2026/10/27 0:47:36 阅读全文 → requests+BeautifulSoup：爬虫抓取h1标题的入门实战指南 简介：一份以实战为导向的Python爬虫入门资源，面向具备基本编程基础、希望快速掌握网络数据抓取的初学者，可解决从零编写简单爬虫的常见困惑。实例以requests库发送HTTP请求、BeautifulSoup解析HTML文档，完整演示从网页中提取 标题… 2026/10/27 0:47:36 阅读全文 → OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析 简介：这是一份面向图形学求职者与3D开发者的OpenGL面试题资料，围绕计算机图形学核心考点整理，适合准备图形渲染、游戏引擎方向面试的中高级开发者查漏补缺。压缩包内共1个doc文档，约19KB，内容以问答形式覆盖渲染对象矩… 2026/10/27 0:47:36 阅读全文 → AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践 简介：《如何构建并实践AI赋能的精准知识产权运营供需匹配平台？》是一份面向政府科技管理部门、高校科研转化机构、技术转移服务商及企业创新负责人的专题文档，聚焦科技成果转化中信息不对称、资源分散、供需对接不畅等问题。压缩包共1个docx文… 2026/10/27 0:00:26 阅读全文 → DeepSeek进阶指南：能力地图、推理模型选型与提示语策略 简介：《DeepSeek从入门到精通》是一份面向AI初学者、内容创作者与开发者的PDF讲义，聚焦国产大模型DeepSeek的基础认知与进阶使用，帮助读者理解其能力边界，并解决模型选择与提示语设计中的实际问题。压缩包内为1个PDF文件&#xff… 2026/10/27 0:00:26 阅读全文 → 数据仓库分层建模：ODS/DWD/DWS/ADS四层设计与边界守则 简介：本资源是一份面向数据工程师、数仓开发人员及大数据初学者的系统性实践指南，聚焦数据仓库中核心难点——数据模型设计方法论与分层落地规范。内容覆盖ODS/CDM（含DWD、DWS、DIM）/ADS全链路分层逻辑、总线矩阵构建、数据域划分… 2026/10/27 0:00:26 阅读全文 → 我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 13:09:34 阅读全文 → Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证 /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/27 17:27:39 阅读全文 → 2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置） /* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … 2026/10/26 20:37:24 阅读全文 →