字节-社招-6年（3-1） · 第 1 轮 · 二面

// 设计稿颜色变量转换示例
const designColors = {
  primary: '#1890ff',
  secondary: '#f0f2f5',
  // ...
};

const cssVariables = Object.entries(designColors).map(
  ([key, value]) => `--color-${key}: ${value};`
).join('\n');

// 输出到全局CSS变量，方便样式统一使用

/* 生成的响应式媒体查询 */
@media (max-width: 768px) {
  .container {
    display: flex;
    flex-direction: column;
  }
}

#### 2. 弹性布局（Flexbox）

* Flexbox 通过灵活的伸缩、对齐和分布特性，自动适配不同屏幕宽度的内容排列。
* 适用于一维布局（行或列），能解决复杂对齐问题。
* 常配合媒体查询使用，实现多端适配。

#### 3. 网格布局（CSS Grid）

* Grid 提供二维布局能力，能更精确地定义行列大小和区域分布。
* 适合复杂页面的动态网格结构设计。

#### 4. 相对单位和视口单位

* 使用 `rem`、`em` 单位代替固定像素，适应用户字体大小和缩放设置。
* 利用视口单位 `vw`、`vh` 根据屏幕大小动态设置宽高。
* 结合动态根字体大小（比如设置 `html { font-size: 100vw / 10; }`），实现等比例缩放。

#### 5. 动态根字体（动态 REM）

* 通过 JS 或 CSS 设置根元素字体大小，基于当前视口宽度动态调整，配合 rem 实现等比例缩放。

```js
function setRem() {
  const docEl = document.documentElement;
  const clientWidth = docEl.clientWidth;
  if (!clientWidth) return;
  // 设计稿宽度为 375px，按比例设置根字体
  docEl.style.fontSize = (clientWidth / 375) * 16 + 'px';
}
window.addEventListener('resize', setRem);
setRem();
```

#### 6. 图片和媒体的适配

* 使用响应式图片（`<picture>`、`srcset`）和媒体查询，根据设备条件加载不同尺寸资源，节省流量提升性能。

#### 7. 视口（viewport）配置

* 在移动端通过合理设置 `&lt;meta name="viewport"&gt;` 标签控制缩放、宽度匹配等。

```html
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" />
```

---

### 三、项目中的实践场景

* **移动优先设计**：先设计小屏样式，再通过媒体查询为大屏增加样式。
* **模块化布局组件**：封装响应式容器组件，动态根据屏幕宽度调整布局结构。
* **多端统一布局方案**：结合 Flex/Grid，动态切换布局模式，实现统一维护。
* **结合 JS 动态调整**：针对特殊需求，监听窗口尺寸变化动态调整部分元素样式。

---

### 四、常见误区与陷阱

* ❌ 直接使用固定像素尺寸，导致不同屏幕显示失衡。
* ❌ 滥用媒体查询，导致样式冗余且难维护。
* ❌ 只关注宽度适配，忽视设备方向和屏幕分辨率差异。
* ❌ 根字体设置不合理，导致 rem 失效或比例异常。
* ❌ 忽视图片和媒体文件的适配，影响加载性能。

---

### 五、总结观点

动态布局适配依赖响应式设计理念，通过媒体查询、弹性布局、网格布局、视口单位及动态根字体等技术，实现页面根据不同设备自动调整，确保视觉和交互体验一致。结合良好的设计体系和代码结构，可有效降低开发维护成本，提升用户满意度。

</details>

## 4. 小程序日志与监控服务中做了哪些事情？全链路优化方案讲一下 {#question-subjective-ae7666de790d}

### 题目要点

- 说明日志采集、异常监控、性能监控内容<br>
- 阐述全链路监控架构及关键技术环节<br>
- 举例说明如何利用监控数据推动优化<br>
- 指出实际运维中的常见问题和对策

<details>
<summary>参考答案</summary>

### 考察点

#### ● 理解小程序日志和监控体系的核心作用<br>
#### ● 掌握日志采集、异常监控、性能指标跟踪技术<br>
#### ● 熟悉全链路监控的设计思路和实践方法<br>
#### ● 能系统阐述如何利用监控数据指导性能与稳定性优化<br>

---

### 参考答案

### 一、小程序日志与监控服务的核心内容

#### 1. 日志采集

- **错误日志**：捕获 JS 运行时错误、接口请求失败、业务异常等。<br>
- **行为日志**：记录用户操作行为、页面访问路径、点击事件等，辅助行为分析。<br>
- **性能日志**：采集启动时间、渲染时间、接口响应时长、白屏时间等关键性能指标。<br>

#### 2. 监控体系搭建

- **异常监控**：实时监控错误日志，支持错误分级、告警通知（邮件、钉钉、短信等）。<br>
- **性能监控**：分析关键路径的耗时，监测用户端性能指标趋势，发现瓶颈。<br>
- **链路追踪**：结合接口请求、前端性能、后端服务日志，构建完整请求链路视图。<br>
- **日志聚合与分析**：使用日志收集平台（如 ELK、Sentry、Datadog）统一管理和分析数据。<br>

#### 3. 用户体验监测（RUM）

- 采集真实用户的加载速度、交互流畅度、异常率等，辅助精准优化。

---

### 二、全链路监控与优化方案

#### 1. 数据采集层

- 小程序端埋点 SDK，自动捕获各种日志与性能数据。<br>
- 采集网络请求的详细信息（请求地址、耗时、状态码等）。<br>
- 采集用户行为和关键操作流程数据。<br>

#### 2. 数据传输与存储层

- 使用消息队列和缓存机制，保证数据稳定传输。<br>
- 建立高效的日志存储和索引结构，支持快速查询。<br>

#### 3. 数据处理与分析层

- 实时分析错误频次、分布和趋势。<br>
- 聚合性能指标，识别热点和异常。<br>
- 利用链路追踪分析跨系统调用和接口瓶颈。<br>

#### 4. 告警与反馈层

- 设计分级告警规则，区分紧急和非紧急问题。<br>
- 自动触发通知到相关负责人和团队。<br>
- 支持故障自愈和快速定位。<br>

---

### 三、优化实践举例

- **白屏时间优化**：通过日志监控快速定位渲染阻塞问题，优化资源加载顺序，减少首屏渲染时间。<br>
- **接口性能监控**：发现慢接口，推动后端接口优化或前端缓存方案。<br>
- **异常率下降**：通过错误日志分析修复高频报错代码，提升稳定性。<br>
- **用户行为分析**：根据用户路径日志优化关键流程，减少跳出率。<br>

---

### 四、常见误区与挑战

- ❌ 只关注错误日志，忽视性能和用户体验数据。<br>
- ❌ 监控指标过多，导致噪声干扰，难以聚焦重点。<br>
- ❌ 采集数据不完整或不准确，影响分析效果。<br>
- ❌ 告警频繁且不分级，导致“告警疲劳”。<br>
- ❌ 未能实现前后端及多系统链路统一监控。<br>

---

### 五、总结观点

小程序日志与监控服务是保障产品稳定性和用户体验的关键基础。通过全链路监控，结合自动化告警和数据分析，可以实现对系统健康状态的实时掌握和精准优化，推动持续改进和高质量交付。

</details>

## 5. 作为前端负责人做了哪些基建 {#question-subjective-ea70cecadf6a}

### 题目要点

- 阐述基建的目标与价值<br>
- 详述脚手架、组件库、构建部署、代码质量保障方案<br>
- 强调性能监控和异常告警体系建设<br>
- 介绍设计规范和团队协作机制<br>
- 避免片面技术视角，注重流程和文化结合

<details>
<summary>参考答案</summary>

### 考察点

#### ● 理解前端基础设施建设的重要性与核心内容<br>
#### ● 掌握构建自动化、质量保障、开发效率提升等关键环节<br>
#### ● 熟悉团队协作流程与技术规范制定<br>
#### ● 能结合实际经验，提出系统化的基建方案<br>

---

### 参考答案

### 一、前端基建的核心目标

- **提升团队开发效率**：减少重复劳动，优化开发流程。<br>
- **保障代码质量**：避免潜在风险，提升代码可维护性。<br>
- **保证系统稳定和性能**：通过规范和自动化，减少生产环境问题。<br>
- **支持持续集成与持续交付（CI/CD）**：快速迭代上线，提升响应速度。<br>

---

### 二、关键基建内容和实践

#### 1. 项目脚手架与组件库建设

- 搭建统一的前端脚手架模板，集成常用技术栈（如 React/Vue、TypeScript、Lint、格式化工具等），降低新项目启动门槛。<br>
- 开发并维护公司或团队级公共组件库，确保UI一致性和复用性，提高开发效率和体验。<br>

#### 2. 自动化构建与部署流水线

- 配置完善的构建工具链（Webpack、Vite等），支持多环境打包优化。<br>
- 搭建自动化部署流程，实现代码提交自动构建、测试、部署。<br>
- 引入灰度发布、回滚机制保障发布安全。<br>

#### 3. 代码质量保障体系

- 统一代码规范（ESLint、Prettier），强制代码格式和规范检查。<br>
- 集成单元测试、集成测试框架（如 Jest、Cypress），并纳入CI流程。<br>
- 引入代码覆盖率工具，定期评估测试质量。<br>
- 设立代码审核流程（PR 评审），提升代码质量和团队协作。<br>

#### 4. 性能监控与异常告警

- 搭建前端性能监控平台，采集关键性能指标（首屏时间、交互耗时等）。<br>
- 集成异常监控工具（Sentry、Raven等），实现实时错误上报与告警。<br>
- 结合日志与监控数据，持续推动性能与稳定性优化。<br>

#### 5. 统一设计规范与设计交付

- 制定设计系统与UI规范文档，推动设计与研发无缝对接。<br>
- 搭建设计稿与代码样式还原自动化工具链（如 Design to Code）。<br>

#### 6. 团队协作与知识管理

- 制定前端开发规范、文档标准和最佳实践手册。<br>
- 搭建内部知识库、技术分享平台，促进经验沉淀与传承。<br>
- 组织定期技术培训与代码复盘，提升团队整体能力。<br>

---

### 三、实际成效与价值体现

- 显著缩短项目启动时间，提高开发效率20%-30%。<br>
- 代码规范和自动化测试覆盖率提升，减少线上Bug率。<br>
- 持续监控告警体系保障产品稳定，提升用户体验。<br>
- 团队协作流程优化，提升沟通效率和开发质量。<br>

---

### 四、常见误区与注意点

- ❌ 基建只关注技术工具，忽视团队流程和文化建设。<br>
- ❌ 建设过度复杂的脚手架，导致新成员学习成本高。<br>
- ❌ 忽视持续维护，基建工具逐渐失效。<br>
- ❌ 缺少业务侧反馈，基建与业务需求脱节。<br>

---

### 五、总结观点

作为前端负责人，体系化的基础设施建设不仅是技术层面的优化，更是推动团队协作、保障业务稳定和持续交付的关键。通过标准化工具链、自动化流程、质量保障和知识沉淀，打造高效、稳定、可持续的前端技术体系，为业务快速发展保驾护航。

</details>

## 6. 富文本编辑器是如何实现的 {#question-subjective-e060725e1327}

-  选区一致性如何保障
  -  协同编辑冲突解决有遇到么 ，怎么解决的？

### 题目要点

- 说明富文本编辑器核心实现原理<br>
- 详细阐述选区一致性的技术手段和难点<br>
- 明确协同编辑中冲突类型及解决算法（OT/CRDT）<br>
- 结合实际经验谈协同编辑解决方案和挑战<br>
- 避免泛泛而谈，结合技术细节和具体方法

<details>
<summary>参考答案</summary>

### 考察点

#### ● 理解富文本编辑器的基本实现原理<br>
#### ● 掌握选区（Selection）管理及一致性保障方法<br>
#### ● 了解协同编辑中的冲突类型及解决思路<br>
#### ● 熟悉常见协同编辑算法和实践案例<br>

---

### 参考答案

### 一、富文本编辑器实现原理

- 富文本编辑器本质是一个复杂的内容可编辑区域，支持多样化文本格式、样式及嵌入元素。<br>
- 核心技术包括操作DOM（contentEditable）、选区管理、数据结构设计、渲染与命令执行等。<br>
- 常用实现方式：基于浏览器原生 `contentEditable` 属性，结合虚拟DOM或自定义数据模型维护编辑状态。<br>

---

### 二、选区一致性保障

#### 1. 选区（Selection）基本概念

- 选区指用户当前高亮或光标所在的文本区域。浏览器通过 `window.getSelection()` 提供选区对象。<br>
- 编辑器需精确维护选区位置，保障光标和高亮不会在操作中丢失或错位。<br>

#### 2. 选区一致性挑战

- 编辑过程中，DOM结构频繁变化（如插入节点、删除文字），导致原生选区失效或偏移。<br>
- 不同浏览器对选区API的支持和表现存在差异。<br>

#### 3. 保障手段

- **保存与恢复机制**：操作前保存选区信息（如锚点和焦点节点偏移），操作后根据当前DOM结构恢复选区。<br>
- **使用标记占位符**：插入不可见的标记元素（如零宽度空格或特定标记节点）辅助定位选区。<br>
- **基于数据模型映射选区**：编辑器维护独立的文档模型（如树结构），根据模型定位选区，避免直接依赖DOM。<br>
- **统一封装跨浏览器选区操作API**，屏蔽差异。<br>
- **防止编辑命令破坏选区**：对富文本命令操作包装，确保选区同步更新。<br>

---

### 三、协同编辑冲突解决

#### 1. 协同编辑冲突类型

- **并发插入冲突**：多个用户同时在同一位置插入内容。<br>
- **并发删除冲突**：不同用户删除同一区域内容。<br>
- **编辑顺序不一致**：不同客户端操作顺序不同导致数据不一致。<br>

#### 2. 常见冲突解决策略

- **Operational Transformation (OT)**<br>
  - 核心思想是将并发操作转换成顺序兼容的操作序列。<br>
  - 通过转换算法调整操作的执行顺序，确保所有客户端最终一致。<br>
  - 应用实例：Google Docs。<br>

- **Conflict-free Replicated Data Types (CRDT)**<br>
  - 利用数学数据类型设计，支持无冲突的并发操作合并。<br>
  - 每个操作可在本地无序执行，最终合并时保证一致性。<br>
  - 优点是简化服务器逻辑，支持离线编辑。<br>

#### 3. 实践中的解决方案

- 设计基于 OT 或 CRDT 的底层算法层，抽象出编辑操作。<br>
- 利用唯一标识符和操作序列号维护操作顺序和版本。<br>
- 设计冲突检测与自动合并机制，避免人工干预。<br>
- 结合实时通信（如 WebSocket）同步编辑操作。<br>
- 对UI层做操作回放与冲突提示，增强用户体验。<br>

---

### 四、项目经验与注意点

- 协同编辑复杂度高，建议优先选用成熟开源库（如 ShareDB、Yjs、Automerge）或商业方案。<br>
- 选区管理与协同编辑需深度耦合，保证多用户环境下光标和选区准确显示。<br>
- 性能优化不可忽视，尤其是大文档和高并发时的响应速度。<br>
- 关注多端一致性，移动端与PC端的编辑体验需统一。<br>

---

### 五、总结观点

富文本编辑器的选区一致性是保证用户操作体验的关键，通过保存恢复、标记辅助和模型映射等方式保障。协同编辑中的冲突解决则依赖 OT 或 CRDT 算法，实现多用户操作的有序合并，保障数据一致性和编辑流畅性。两者结合，构成高质量富文本协作编辑器的基础。

</details>

## 7. 在项目的质量与稳定性方面做过哪些工作 {#question-subjective-22588adede6b}

### 题目要点

- 介绍代码规范和审核机制<br>
- 说明测试体系的搭建及自动化集成<br>
- 阐述异常监控和性能监控方法<br>
- 分享具体优化案例和效果<br>
- 提醒避免常见误区，注重体系完整性

<details>
<summary>参考答案</summary>

### 考察点

#### ● 理解项目质量与稳定性的重要性及核心指标<br>
#### ● 熟悉前端测试体系和自动化流程建设<br>
#### ● 掌握异常监控、性能监控和回归保障方法<br>
#### ● 能结合实际经验描述质量提升和稳定性保障的全流程<br>

---

### 参考答案

### 一、项目质量保障工作

#### 1. 代码规范与审核机制

- **制定统一的代码规范**（如 ESLint、Prettier），确保代码风格一致，减少潜在错误。<br>
- **强制代码评审（PR 审核）**，通过多人审核避免低质量代码合入主干。<br>
- **引入静态类型检查**（TypeScript），提前发现类型相关问题。<br>

#### 2. 测试体系建设

- **单元测试**：覆盖核心逻辑和组件，保证模块正确性。<br>
- **集成测试**：验证模块间交互是否符合预期。<br>
- **端到端测试（E2E）**：模拟用户场景，确保整体业务流程稳定。<br>
- **自动化测试集成 CI/CD**：代码提交即触发测试，及时发现回归和缺陷。<br>

#### 3. 持续集成与自动化流程

- 搭建自动构建和部署流水线，确保代码质量门槛。<br>
- 集成代码覆盖率报告，定期评估测试有效性。<br>
- 通过自动化工具执行安全扫描和性能检测。<br>

---

### 二、项目稳定性保障工作

#### 1. 异常监控与日志分析

- 集成前端异常监控工具（如 Sentry、Bugsnag），实时捕获 JS 错误和接口异常。<br>
- 设计日志规范，收集关键业务和性能指标，辅助定位问题。<br>
- 设置告警规则，第一时间通知相关人员响应。<br>

#### 2. 性能监控与优化

- 采集关键性能指标（如白屏时间、首次输入延迟、交互耗时）。<br>
- 定期分析性能瓶颈，推动代码和资源优化。<br>
- 实施资源预加载、懒加载和代码分割，提升响应速度和流畅度。<br>

#### 3. 回归测试与版本管理

- 每次版本发布前执行全面回归测试，保证新版本稳定。<br>
- 制定版本回滚策略，应对突发线上故障。<br>

---

### 三、项目质量与稳定性提升案例

- 通过推行严格的代码规范和自动化测试，项目线上Bug率下降40%。<br>
- 引入异常监控后，错误响应时间缩短50%，用户体验显著提升。<br>
- 利用性能监控数据，优化资源加载顺序，首屏加载时间缩短30%。<br>
- CI/CD流水线的建设大幅度缩短了发布周期，提升了发布安全性。<br>

---

### 四、常见误区与挑战

- ❌ 测试覆盖率高但测试质量低，缺乏有效断言。<br>
- ❌ 异常监控数据堆积无分析，导致告警疲劳。<br>
- ❌ 忽视回归测试和版本管理，线上问题频发。<br>
- ❌ 只关注功能上线，忽略性能和用户体验指标。<br>

---

### 五、总结观点

保障项目质量与稳定性是一个系统工程，涵盖规范流程、自动化测试、持续集成、实时监控和性能优化等多个环节。通过科学的体系建设和不断迭代，能有效降低风险、提升产品稳定性和用户满意度，是前端负责人及团队必须持续关注的重点。

</details>

## 8. 代码题】描述下列代码的输出结果和原因 {#question-subjective-70bfaa340be9}

```js
async function foo() {
  console.log(1);
  await Promise.resolve().then(() => console.log(2));
  console.log(3);
}
setTimeout(() => console.log(4));
foo();
new Promise(resolve => resolve()).then(() => console.log(5));
console.log(6);
```

### 题目要点

- 明确 async/await 本质是基于 Promise 的语法糖<br>
- 理解微任务与宏任务队列的执行顺序<br>
- 清晰分析事件循环流程中代码执行时机<br>
- 结合代码逐步说明每个输出产生的时间点<br>
- 避免简单背诵，突出机制原理和执行细节

<details>
<summary>参考答案</summary>

### 考察点

#### ● 理解 async/await 与 Promise 的执行机制<br>
#### ● 掌握 JavaScript 事件循环中宏任务和微任务的执行顺序<br>
#### ● 能准确分析复杂异步代码的输出顺序及原因<br>

---

### 参考答案

### 一、代码输出及顺序

```

1
6
2
5
3
4

```

### 二、原因分析

#### 1. 代码执行流程解析

- `foo()` 是异步函数，调用时执行到第一个同步语句 `console.log(1)`，立即输出 `1`。<br>
- `await Promise.resolve().then(() => console.log(2))`：<br>
  - `Promise.resolve().then()` 返回一个微任务，里面的回调 `console.log(2)` 会被加入微任务队列。<br>
  - `await` 后面的代码 `console.log(3)` 会被拆分到 `await` 后的后续微任务中执行。<br>
- `setTimeout(() => console.log(4))`：这是宏任务，后续执行。<br>
- `new Promise(resolve => resolve()).then(() => console.log(5))`：立即生成微任务，打印 `5` 会在同步代码后执行。<br>
- `console.log(6)` 是同步代码，立即执行输出 `6`。<br>

#### 2. 事件循环阶段执行顺序

- **同步代码执行阶段**：<br>
  - `console.log(1)` 输出 `1`<br>
  - `console.log(6)` 输出 `6`<br>
  - `foo()` 内部 `await` 遇到 Promise.then 微任务等待，后续代码暂停执行。<br>
- **微任务执行阶段（当前宏任务结束后）**：<br>
  - `console.log(2)`（`await` 内部的 Promise.then）<br>
  - `console.log(5)`（外部 Promise.then）<br>
  - `console.log(3)`（`await` 后续代码继续执行）<br>
- **宏任务执行阶段**：<br>
  - `setTimeout` 回调执行，输出 `4`<br>

---

### 三、总结

- `async/await` 会让函数遇到 `await` 时暂停执行，等待 Promise 解决后继续执行后续代码。<br>
- `Promise.then` 注册的回调属于微任务，会在当前宏任务结束后立即执行。<br>
- `setTimeout` 属于宏任务，优先级低于微任务，需等待所有微任务执行完后才会执行。<br>
- 因此输出顺序为：1（同步）→ 6（同步）→ 2（微任务）→ 5（微任务）→ 3（await 后续微任务）→ 4（宏任务）。

</details>

## 9. 代码题】版本号排序算法实现 {#question-subjective-07c063aa96f5}

-  处理含预发布版本（如1.0.0-alpha.1 < 1.0.0）<br>
  -  支持非数字版本段（按字典序比较）

### 题目要点

* 明确版本号的语义结构与比较规则
* 实现分割与逐段比较逻辑
* 兼顾预发布版本的特殊排序规则
* 提供清晰可运行的示例代码
* 强调边界和异常情况处理

<details>
<summary>参考答案</summary>

### 考察点

#### ● 理解语义化版本（SemVer）规范及预发布版本排序规则<br>
#### ● 掌握字符串和数字混合比较的设计思路<br>
#### ● 能实现健壮、支持预发布的版本排序算法<br>
#### ● 熟悉边界条件处理和性能优化<br>

---

### 参考答案

### 一、版本号排序原理

- **语义化版本格式**：`MAJOR.MINOR.PATCH[-PRERELEASE]`，例如 `1.0.0`, `1.0.0-alpha.1`<br>
- **排序规则**：<br>
  - 主版本号（MAJOR）、次版本号（MINOR）、补丁号（PATCH）均为数字，逐级比较大小。<br>
  - 若版本号完全相等，则比较预发布版本：无预发布 > 有预发布（即稳定版优先）。<br>
  - 预发布版本由多个点分割的标识组成，支持数字和字母，比较规则：数字 < 字母，数字按数值比较，字母按字典序比较。<br>
  - 预发布版本缺少部分视为更小版本，例如 `alpha &lt; alpha.1`。<br>

---

### 二、算法实现思路

1. **分割版本字符串**：<br>
   - 使用 `-` 分割主版本和预发布版本。<br>
   - 使用 `.` 分割主版本号段和预发布版本号段。<br>

2. **主版本号比较**：<br>
   - 转为数字，逐段比较，发现差异立即返回结果。<br>

3. **预发布版本比较**：<br>
   - 无预发布版本号视为最高优先级（大于任何预发布版本）。<br>
   - 有预发布时，分段逐一比较：<br>
     - 若两段均为数字，按数字大小比较。<br>
     - 若一段是数字，另一段是字母串，数字 < 字母串。<br>
     - 若均为字符串，按字典序比较。<br>
     - 如果一方提前结束（段数少），则较短的版本号更小。<br>

4. **返回最终比较结果**，支持排序接口。<br>

---

### 三、示例代码（JavaScript）

```js
function compareVersion(v1, v2) {
  // 拆分主版本和预发布版本
  const [main1, pre1] = v1.split('-', 2);
  const [main2, pre2] = v2.split('-', 2);

  const mainParts1 = main1.split('.').map(Number);
  const mainParts2 = main2.split('.').map(Number);

  // 主版本号逐段比较
  for (let i = 0; i < Math.max(mainParts1.length, mainParts2.length); i++) {
    const num1 = mainParts1[i] || 0;
    const num2 = mainParts2[i] || 0;
    if (num1 > num2) return 1;
    if (num1 < num2) return -1;
  }

  // 主版本相等，比较预发布版本
  // 无预发布版本 > 有预发布版本
  if (pre1 === undefined && pre2 === undefined) return 0;
  if (pre1 === undefined) return 1;
  if (pre2 === undefined) return -1;

  // 预发布版本拆分
  const preParts1 = pre1.split('.');
  const preParts2 = pre2.split('.');

  const len = Math.max(preParts1.length, preParts2.length);
  for (let i = 0; i < len; i++) {
    const part1 = preParts1[i];
    const part2 = preParts2[i];

    // 预发布版本短的更小
    if (part1 === undefined) return -1;
    if (part2 === undefined) return 1;

    const isNum1 = /^\d+$/.test(part1);
    const isNum2 = /^\d+$/.test(part2);

    if (isNum1 && isNum2) {
      // 都是数字，数字大小比较
      const num1 = Number(part1);
      const num2 = Number(part2);
      if (num1 > num2) return 1;
      if (num1 < num2) return -1;
    } else if (isNum1) {
      // 数字 < 字符串
      return -1;
    } else if (isNum2) {
      return 1;
    } else {
      // 都是字符串，字典序比较
      if (part1 > part2) return 1;
      if (part1 < part2) return -1;
    }
  }

  return 0;
}

// 用法示例
const versions = [
  '1.0.0-alpha',
  '1.0.0-alpha.1',
  '1.0.0-alpha.beta',
  '1.0.0-beta',
  '1.0.0-beta.2',
  '1.0.0-beta.11',
  '1.0.0-rc.1',
  '1.0.0'
];

versions.sort(compareVersion);

console.log(versions);
/*
输出顺序：
[
  '1.0.0-alpha',
  '1.0.0-alpha.1',
  '1.0.0-alpha.beta',
  '1.0.0-beta',
  '1.0.0-beta.2',
  '1.0.0-beta.11',
  '1.0.0-rc.1',
  '1.0.0'
]
*/