Docs

Docs Menu

索引

Lifelong Learning

什么是终身学习？
终身学习的重要性
- 我们都是终身学习者
- 终身学习的关键清单
终身学习的例子
终身学习的好处
我需要积极主动地进行终身学习吗？
如何在生活中采用终身学习？

Frontend

前端常用工具链

状态管理

Pinia

Pinia 总览：Vue 3 官方状态管理与 Vuex 对照

Pinia 是什么：带名字的响应式容器
为什么 Vue 3 生态默认是它，而不是继续押 Vuex
在应用里，Pinia 和谁分工？
安装与挂载：应用里长什么样
小结：先选对「放哪」，再谈怎么写 store

Pinia 核心：state、getters 与 actions 数据流

state：唯一真相源，但要控制粒度
getters：Store 层的「计算属性」
actions：异步与副作用的默认入口
数据流怎么走：一个最小闭环
常见坑：解构丢失响应式
小结：三块各司其职

Pinia 组合式 Store：setup 写法与拆分

setup store 是什么：几乎就是在写 composable
拆分策略：按域，而不是按文件类型
storeToRefs：和模板、解构打交道
复用：composable + store 的组合拳
小结：setup store 的本质是「有身份证的全局 composable」

Pinia 插件与持久化：缓存与登录态

插件在 Pinia 里处于什么位置
持久化：存什么、不存什么
刷新与多 Tab：一致性问题
SSR（Nuxt 等）多提一句
小结：插件解决「横切」，持久化解决「生命周期外」

Pinia 与 TypeScript：类型与工程化

类型信息从哪来
Options Store 与 Setup Store 的差异点
在组件里用 store 时的类型体验
与 import type、模块导出
小结：类型是契约，和 store 边界一起设计

Pinia 测试与调试：单测与 DevTools

单测：创建隔离的 pinia 实例
mock 策略：mock store 还是 mock 依赖
DevTools：值得看的几块
小结：可测性来自边界清晰

前端状态管理：Zustand，一个轻量的全局状态方案

基本使用方式：一个 store，一个 hook
选择器与避免多余渲染
切片（slice）和多模块拆分
中间件：持久化、调试和重置
与异步请求配合
和 Context / Redux 的对比
在项目里落地时可以注意的点

前端打包工具对比：从 Webpack 到 Vite 的发展与选择

打包工具的发展历程
主流工具对比
性能对比
选用建议
迁移建议
- 从 Webpack 迁移到 Vite
- 从其他工具迁移
未来趋势
小结

Yarn

安装yarn
yarn 与 npm 命令对比
npm --save 和 npm --save-dev 区别
yarn对比npm的优点

Lerna

关于
入门
如何使用Lerna
- Fixed/Locked 模式 (default)
- Independent 模式
基本概念
自述文件徽章

Node-gyp 与 Node Headers 原理解析

一句话解释
1. 为什么需要 node-gyp？
2. node-gyp 实际做了什么？
3. 什么是 Node Headers？
4. 为什么国内经常卡在下载阶段？
5. 在 IDE / 工具链场景中的典型应用
6. 未来在 AI IDE 中的潜在价值
总结

前端基础

ECMAScript 版本变迁：从 ES5 到 ES2024 的语法演进

ES5（2009）：现代 JavaScript 的起点
- 核心特性
ES6 / ES2015：JavaScript 的“现代化”
- 核心特性
ES2016：小幅更新
ES2017：async/await 的引入
ES2018：异步迭代和对象展开
ES2019：数组和字符串的增强
ES2020：BigInt 和可选链
ES2021：逻辑赋值和数字分隔符
ES2022：类字段和顶层 await
ES2023：数组查找方法
ES2024：数组分组和 Promise.withResolvers
版本变迁对前端开发的影响
小结

JavaScript 异步编程：从回调到 Promise 再到各种骚操作

为什么需要异步？
回调函数：最原始的异步方式
Promise：异步编程的基础
async/await：让异步代码看起来像同步代码
常用操作和模式
实际开发中的最佳实践
小结

JavaScript 中的隐秘问题：那些容易踩的坑

类型转换的陷阱
作用域和变量提升
this 绑定的陷阱
数组的奇怪行为
对象的陷阱
浮点数精度问题
原型链的陷阱
异步相关的陷阱
其他常见的坑
如何避免这些问题
小结

前端中的常用算法：从数据结构到性能优化

数组操作算法
排序算法
查找算法
字符串算法
树和图的算法
缓存算法
- LRU 缓存（Least Recently Used）
- LFU 缓存（Least Frequently Used）
性能优化算法
其他实用算法
小结

TypeScript

TypeScript 高级类型：联合、交叉、字面量类型与类型守卫

联合类型（Union Types）
交叉类型（Intersection Types）
字面量类型（Literal Types）
类型守卫（Type Guards）
类型别名 vs 接口
索引签名和映射类型基础
实际应用场景
- API 响应类型
- 配置对象类型
小结

TypeScript 泛型：从基础到进阶

泛型基础
泛型约束
泛型工具类型
条件类型（Conditional Types）
分布式条件类型
- 实际应用：过滤类型
- 实际应用：提取函数重载的返回类型
实际应用场景
小结

TypeScript 类型操作：类型推断、断言、收窄与兼容性

类型推断（Type Inference）
类型断言（Type Assertions）
类型收窄（Type Narrowing）
类型兼容性
实际应用场景
小结

TypeScript 类与接口：面向对象编程

类的基础
类的继承
抽象类
- 抽象类定义
- 抽象属性
接口（Interfaces）
类实现接口
类与接口的区别
实际应用场景
小结

TypeScript 工具类型：内置工具类型详解

基础工具类型
条件类型工具
函数类型工具
字符串操作工具类型
自定义工具类型
实际应用场景
小结

TypeScript 模块与命名空间

ES 模块
命名空间（Namespaces）
声明合并（Declaration Merging）
模块解析
三斜线指令
- ///
- ///
- ///
模块 vs 命名空间
- 使用模块当：
- 使用命名空间当：
实际应用场景
小结

TypeScript 装饰器与元数据

装饰器基础
- 启用装饰器
- 装饰器工厂
类装饰器
方法装饰器
属性装饰器
- 基础用法
- 实际应用：验证装饰器
参数装饰器
- 基础用法
- 实际应用：依赖注入
访问器装饰器
- 基础用法
元数据反射 API
装饰器执行顺序
实际应用场景
- Angular 风格的依赖注入
- 验证装饰器
小结

TypeScript 配置与工程化

tsconfig.json 基础
- 配置文件结构
- 配置继承
编译选项详解
与构建工具集成
类型声明文件
项目结构
- 单项目结构
- 多项目结构（Project References）
实际应用场景
最佳实践
小结

TypeScript 实战：常见模式与最佳实践

常见设计模式
类型安全的 API 调用
- API 响应类型
- 类型安全的 HTTP 客户端
错误处理模式
- Result 类型
- Option 类型
常见错误和解决方案
最佳实践
性能优化
小结

Symbol

语法
- 参数
描述
- 全局共享的 Symbol
- 在对象中查找 Symbol 属性
属性

前端框架

React

React Hooks 深入与实现思路：useState、useEffect 与自定义 Hooks

useState：渲染快照与更新批处理
- 状态是渲染时刻的快照
- 批量更新与「同步代码里读不到最新值」
useEffect：依赖数组和闭包陷阱
- 依赖数组是「你用到了谁」，不是「你希望谁变化时触发」
- 闭包造成的「过期值」问题
useMemo / useCallback：只优化「贵的那部分」
- 缓存计算结果：useMemo
- 缓存回调引用：useCallback
自定义 Hooks：把「一小撮逻辑」拎出来
- 适合抽成 Hook 的信号
- 粒度控制：不要把一个组件整体包成一个 Hook
小结

React 渲染机制与调度：Fiber、优先级与并发特性

从「一口气渲染到底」到「可中断的渲染」
两个阶段：render 与 commit
优先级与任务调度
并发特性：useTransition 与 useDeferredValue
- useTransition：延后那部分「重的渲染」
- useDeferredValue：延后那份「值的变化」
重渲染与调度：几个容易混淆的点
- 「渲染频率高」不一定等于「卡顿」
- 「打断」不等于「丢掉」
和日常开发的连接点

React 组件设计模式：容器/展示组件、自定义 Hooks 与控制反转

容器组件 vs 展示组件
从容器组件到自定义 Hooks
受控组件与非受控组件
控制反转：让父层决定策略
- 用回调开放关键环节
- 用自定义 Hook 做「业务逻辑的控制反转」
组合优先于继承
小结

React 状态管理策略：从本地 State 到全局 Store

状态的几种「归属」
本地 State：能局部就不要全局
Context：负责「一片区域」的共享
- Context 的性能问题
服务器状态：用「远程状态库」管理
URL 状态：路由是「可分享的状态」
什么时候需要全局 Store？
画一张「状态拓扑图」
小结

React 性能优化实战：重渲染分析与列表优化

先看清楚谁在重渲染
减少不必要的重渲染
- 用 React.memo 缓住稳定的子组件
- 拆分状态，避免「一变全变」
列表优化：key、虚拟化和按需渲染
避免在渲染函数里做重活
和并发特性的配合
小结

React 表单与复杂交互：受控组件、校验与异步提交

受控组件打底
组织表单状态：值、错误、touched、dirty
校验：时机与粒度
- 同步校验
- 异步校验
异步提交与状态反馈
表单库什么时候登场
小结

React 与异步数据：SWR 模型、Suspense 思路与错误边界

SWR 模型：请求不只是“发一次”
用 React Query 管服务器状态
写入与乐观更新
Suspense 思路：把加载当作“渲染的一部分”
错误边界：和异步数据配套出现的那一层
和状态管理的分工
小结

React 路由与应用结构：嵌套路由、布局组件与权限控制

路由与布局：Outlet 和布局组件
URL 即状态：让可以分享的状态进路由
权限控制：路由守卫与 UI 级别的限制
- 路由层的保护（Protected Route）
- UI 层的权限
路由与状态管理的边界
小结

React SSR 与 Hydration：Next.js 中的实践与坑点

SSR / SSG / ISR 是什么区别
Hydration：不是再渲染一遍
Next.js 中的页面渲染模式
客户端组件与服务端组件（App Router）
常见坑点与经验
小结

React 与 TypeScript：组件类型建模、Props、Ref 与多态组件

函数组件的基本类型写法
组合 HTML 属性：在自定义组件上透传原生 props
Ref 转发：forwardRef 的类型写法
受控/非受控组件的联合 props
多态组件：as 属性与元素类型推导
组件组合时的 Props 传递
小结

React 错误处理与稳定性：Error Boundary、日志与降级策略

Error Boundary：拦住渲染阶段的异常
错误边界能捕获什么，不能捕获什么
日志与监控：把错误送到正确的地方
降级策略：局部挂了不代表整站崩盘
与异步请求结合
小结

React 组件库与设计系统：从基础组件到业务组件层

分层：Basic / Composite / Business
基础组件：贴近设计 Token
组合组件：固化交互模式
业务组件：贴业务，不贴基础设施
主题与暗色模式
可访问性（a11y）在组件库里的落地
与第三方 UI 库的关系
小结

Electron：桌面应用壳与前端工程

Electron 架构总览：主进程、渲染进程与进程间通信

1. Electron 的三块拼图：Chromium + Node + 主进程外壳
2. 主进程：应用的“大脑”和系统入口
- 2.1 主进程的职责
- 2.2 BrowserWindow 与 WebContents
3. 渲染进程：前端应用的运行场所
- 3.1 渲染进程的职责
- 3.2 多个渲染进程与多窗口
4. 进程间通信（IPC）：主进程与渲染进程如何对话？
- 4.1 为什么不能「直接调用」？
- 4.2 IPC 的基本模式
5. 推荐的通信与安全模式：preload + contextBridge
6. 与 Web / 后端服务的关系：Electron 并不是「全栈替代品」
7. 小结：理解 Electron 架构时要抓住的几个点

Electron 安全模型：nodeIntegration、contextIsolation 与 preload 脚本

1. 为什么 Electron 的安全风险和普通 Web 不一样？
2. nodeIntegration：不要让渲染进程直接拿到 Node
- 2.1 nodeIntegration 做了什么？
- 2.2 和 XSS 结合时的风险
3. contextIsolation：隔离页面脚本和 preload 脚本
- 3.1 contextIsolation 的作用
- 3.2 为什么要配合 preload 脚本使用？
4. preload 脚本与 contextBridge：构建受控的本地 API
- 4.1 preload 脚本的角色
- 4.2 在这一层做哪些安全设计？
5. 其他关键安全实践（简要罗列）
6. 小结：Electron 应用安全的几条底线

Electron 性能与资源管理：多窗口、多进程与懒加载

1. 多窗口 = 多渲染进程：成本是线性上去的
2. 控制窗口生命周期：不要把所有窗口都当「常驻」
3. 避免在渲染进程里做「重活」
4. 懒加载：把加载压力分散到使用时刻
5. 诊断与调优：用好 DevTools 和性能分析工具
6. 小结：Electron 性能优化的几条主线

Electron 原生体验：菜单、托盘、快捷键与通知集成

1. 菜单（Menu）：不要只把菜单当「命令面板」
- 1.1 菜单适合承担的角色
- 1.2 菜单与渲染进程的配合
2. 托盘（Tray）：适合哪些应用形态？
- 2.1 托盘图标的典型用法
- 2.2 托盘与窗口生命周期的关系
3. 快捷键（globalShortcut）：慎用全局加分项
- 3.1 全局快捷键适用的场景
- 3.2 使用时需要注意的问题
4. 通知（Notification）：在不打扰的前提下提供反馈
- 4.1 通知适合干什么？
- 4.2 与业务逻辑的配合
5. 文件与协议关联：把应用嵌进系统工作流
6. 小结：如何设计一套「不违和」的 Electron 原生体验？

Electron 更新与自动更新：发布渠道、版本与安全

1. Electron 应用可以怎么「被安装」？
2. 自动更新的基本思路：客户端拉取「更新信息 + 更新包」
3. 版本与渠道管理：不仅仅是「有新版本就推」
4. 自动更新与安全：防止「把恶意包推给所有用户」
5. 用户体验：让更新「可感知但不打扰」
6. 小结：把 Electron 更新体系看成一个「独立子系统」

Electron 架构反模式与重构建议：从单文件主进程到分层本地服务

1. 反模式一：所有逻辑都堆在主进程里
- 1.1 症状描述
- 1.2 重构方向
2. 反模式二：渲染进程直接开启 Node 能力
- 2.1 症状描述
- 2.2 重构方向
3. 反模式三：IPC 名字和协议散落各处
- 3.1 症状描述
- 3.2 重构方向
4. 反模式四：状态到处是，全局变量横飞
- 4.1 症状描述
- 4.2 重构方向
5. 反模式五：把 Electron 当成「唯一后端」
- 5.1 症状描述
- 5.2 重构方向
6. 小结：从反模式出发，收拢成几条架构原则

Electron 作为 Linux 桌面壳：从 Kiosk 模式到伪桌面环境

1. Electron 在 Linux 桌面栈里的位置
2. Kiosk 模式：登录后只跑一个全屏 Electron 应用
3. 「伪桌面环境」：在 Electron 里包一层壳
4. 启动与守护：让 Electron 成为「登录后的第一屏」
5. 安全与权限：桌面壳并不意味着「什么都能做」
6. 要不要真的「取代」桌面环境和窗口管理器？
7. 小结：一条从应用到「桌面壳」的演进路径

Electron 多窗口复杂应用的状态管理与通信

1. 先搞清楚「状态的归属范围」
2. 哪些状态适合放在主进程 / 本地服务层？
3. 窗口内状态：交给各自的前端状态管理
4. 多窗口之间如何通信？几种常见模式
5. 通信协议的设计：不要只依赖「字符串频道」
6. 典型多窗口应用的几种状态与通信场景
7. 小结：多窗口状态管理的一条基本原则

Electron 跨平台差异与兼容性清单：Windows、macOS 与 Linux

1. 菜单与菜单栏行为的差异
- 1.1 顶栏菜单
- 1.2 右键菜单
2. 托盘图标与 Dock 行为
- 2.1 托盘（系统通知区域）
- 2.2 Dock / 任务栏行为
3. 快捷键与输入法
- 3.1 修饰键与常见组合
- 3.2 输入法与文本处理
4. 窗口行为与最小化/关闭语义
- 4.1 关闭按钮的语义差异
- 4.2 多显示器与全屏
5. 文件系统与路径差异
- 5.1 路径格式与分隔符
- 5.2 用户目录与配置文件位置
6. 打包与签名：平台特定要求
7. 小结：在代码与架构里预留「平台分支」的位置

Electron 与数据库/文件系统的整合：配置、缓存与项目数据

1. 先划清「要存哪些本地数据」的范围
2. 文件系统：合理规划目录结构与权限
- 2.1 存放位置
- 2.2 权限与安全
3. 轻量数据库：什么时候需要 SQLite 之类的内嵌 DB？
4. 数据迁移与版本管理
5. 缓存策略：何时重建、何时清理？
6. 渲染进程不直接读写文件与数据库
7. 小结：把本地存储当成一个「正式的后端」

Electron 与本地后端/微服务的协作模式

1. 三种典型分布：纯远端、纯本地、混合模式
2. 本地嵌入式服务：在 Electron 里「带一个后端」
3. 远端微服务：让 Electron 成为众多客户端中的一个
4. 混合模式下的协作边界设计
5. 通信方式选择：IPC vs HTTP/WS
6. 小结：把 Electron 放在整个系统中的正确位置

Electron 与前端框架的工程实践：以 React/Vue 为例

1. 项目结构：Monorepo 还是分仓？
2. 开发环境：同时调试 Electron 和前端
3. 构建流程：前端打包结果如何和 Electron 集成？
4. 在 React/Vue 应用中为 Electron 做的几件额外事情
5. 类型与接口的共享：前端与主进程之间的契约
6. 小结：把 Electron 和前端框架当成两个协作层

Electron 性能优化实战：CPU、内存与渲染路径的系统梳理

1. 先区分：是谁在「变慢」？
2. CPU 使用：避免在错误的地方做太多「重活」
3. 内存占用：从「一次性多」和「慢慢涨」两类入手
4. 渲染路径优化：让界面「看起来更轻」
5. 主进程与后台任务：别让「不显眼的地方」吃掉资源
6. 建立性能预算与回归检查
7. 小结：用「分层 + 观测」的方式做性能优化

Canvas：从基础绘制到高性能图形

Canvas 基础：坐标系、像素与 2D 绘制上下文

1. <canvas> 元素和 2D 上下文是什么关系？
2. 坐标系与像素：左上角是原点，一切都是浮点数
- 2.1 默认坐标系
- 2.2 坐标是浮点数，像素是离散的
3. 逻辑尺寸与 CSS 尺寸：devicePixelRatio 的影响
- 3.1 为什么同样大小在高清屏上会模糊？
- 3.2 基于 devicePixelRatio 的简单适配思路
4. 基础绘制 API：矩形、路径与颜色
5. 状态的概念：Canvas 是有「记忆」的
6. 小结：第一步先把「画布」这件事弄清楚

Canvas 变换矩阵：translate/rotate/scale 的心智模型

1. 把「坐标系」当成会动的东西
2. translate(x, y)：移动原点
3. rotate(angle)：围绕原点旋转坐标系
- - 3.1 围绕任意点旋转的套路
4. scale(sx, sy)：缩放坐标系
5. 顺序很重要：变换是「右乘叠加」的
6. save / restore：管理变换与样式的栈
7. 视图缩放与平移：用变换实现「画布移动」
8. 小结：用统一的心智模型看待 Canvas 变换

Canvas 动画基础：requestAnimationFrame、时间步长与简单性能优化

1. 为什么用 requestAnimationFrame 而不是 setInterval？
2. 基于时间的动画设计：让速度和帧率解耦
3. 清屏与重绘：不要每一帧都画「无用像素」
4. 离屏 Canvas：把「不必每帧计算的东西」提前算好
5. 控制更新频率：不一定所有东西都要 60fps
6. Debug 与测量：用眼睛 + 工具双重验证
7. 小结：先让动画「正确」，再让动画「更快」

Canvas 路径与形状：从直线、曲线到复合路径

1. 路径的基本生命周期：构造 → 填充/描边 → 可选复用
2. 直线与折线：moveTo / lineTo
3. 圆与圆弧：arc 与 arcTo
- 3.1 arc：以中心 + 半径 + 角度画圆/圆弧
- 3.2 arcTo：用于圆角连接
4. 曲线：quadraticCurveTo 与 bezierCurveTo
- 4.1 二次贝塞尔：quadraticCurveTo
- 4.2 三次贝塞尔：bezierCurveTo
5. 复合路径与「洞」：多次 beginPath 与填充规则
6. 工程实践：把复杂形状封装成函数
7. 小结：路径是 Canvas 绘制的「语法树」

Canvas 文本绘制：字体、对齐与测量

1. 基本 API：fillText / strokeText 与 font
2. textAlign 和 textBaseline：决定 (x, y) 在文字中的位置
- 2.1 水平对齐：textAlign
- 2.2 垂直基线：textBaseline
3. 文本清晰度与高 DPI 适配
4. 文本测量：用 measureText 辅助布局
5. 文本与背景图形的协作：边界与留白
6. 小结：把文本当成「一等公民」来看待

Canvas 图片绘制与像素操作：drawImage、getImageData 到简单滤镜

1. drawImage：从简单绘制到九宫格裁剪
2. 图片与坐标系、变换配合使用
3. 像素操作基础：getImageData 与 putImageData
4. 简单滤镜示例：灰度与反色
- 4.1 灰度处理
- 4.2 反色处理
5. 性能与边界注意事项
6. 小结：把图片看成「可以被重组的像素源」

Canvas 合成与透明度：globalAlpha 与 globalCompositeOperation 常见用法

1. globalAlpha：为所有绘制加上一层统一透明度
2. globalCompositeOperation：控制新内容如何与已有内容「混合」
3. 擦除效果：用 destination-out 做橡皮擦
4. 蒙版效果：用 source-in / destination-in 做遮罩
5. 光效叠加：用 lighter 模拟发光
6. 使用这些状态时的工程注意事项
7. 小结：用合成与透明度组合出更丰富的图形语言

Web IDE 开发笔记

Theia 架构解析

Lumino：桌面感窗口系统的前世今生

Lumino 的 Widget 系统：从概念到源码入口

Widget 在 Lumino 里的角色
一个最小可跑的 Lumino Widget Demo
Widget 的生命周期：attach/detach/resize/update
Widget 与容器：Panel / DockPanel / TabBar 的关系
Widget 与信号/命令：更大一层的协作
写在最后：为什么先啃 Widget 再看 Theia？

Lumino 的 signaling 和 messaging：状态与生命周期的底噪

先分清楚：signaling vs messaging 到底谁管啥？
signaling：在 Widget / 模型之间传递“我变了”的信号
signaling + Widget 的一个组合小例子
messaging：Widget 生命周期背后那条消息泵
signaling + messaging 在实际阅读代码时的用法区别
小结：为什么我愿意为这俩单独写一篇？

Lumino 的布局系统：DockPanel / SplitPanel / TabBar 一条龙

布局的基本思路：一堆容器 Widget 叠罗汉
SplitPanel：最基础的“可拖动分隔条”
TabBar / TabPanel：一组 Widget 共用一个“框”，靠 Tab 切换
DockPanel：把 Split + Tab 全打包了
布局数据的持久化和恢复（IDE 必备套路）
这些布局 Widget 在 Theia 里的大致落位
小结：把这几块积木认清楚，再看 IDE 布局就不那么迷幻了

Lumino 的 command 系统：把行为从按钮里解放出来

先理解一下：为什么需要 command 系统？
CommandRegistry：命令的集中注册中心
命令与快捷键：addKeyBinding、键盘处理与 FocusTracker
命令与菜单/按钮：不同入口复用同一段逻辑
命令参数与上下文：不只是“开关”动作
在 Theia / Lumino 源码里看 command 的一些观察点
小结：command 系统 = 行为的“中枢神经”

Lumino 的应用骨架：Application + 菜单 / 工具栏 / 右键菜单

@lumino/application：把零散的能力装进一个 App
一个极简 Lumino Application 骨架
菜单栏：Menu + MenuBar
右键菜单：ContextMenu
工具栏：一组“命令按钮”的容器
把这些拼回 Application 视角
小结：Application + 菜单体系 = 把“命令世界”塞进一个真正的 App

Lumino 的 virtualdom：轻量 VDOM、对比 React/Vue 以及如何结合使用

@lumino/virtualdom 是什么？
和 React/Vue 的对比：它刻意“不长大”的地方
在 Widget 里使用 virtualdom：一个完整小例子
如果工程里已经有 React/Vue，要怎么和 Lumino 配合？
和 React/Vue 相比，什么时候更适合用 Lumino 自己的 virtualdom？

Lumino 的 disposable 与组件生命周期：东西造出来，总要有人负责善后

@lumino/disposable：一个很小但到处都在用的模式
把 disposable 和 Widget 生命周期结合起来
常见组件的生命周期：从 Application 到 Widget
在 Theia/Lumino 里看“生命周期 + 资源释放”的几个观察点
小结：disposable 是“看不见，但处处在”的一层保障

Lumino 的性能与优化：与 React 的对比思考

先说定位：Lumino 关心的“性能问题”跟普通业务前端不太一样
Lumino 层面的性能基石：三块砖
和 React 的几个典型对比点
在 Lumino 里常见的几个性能坑 & 优化思路
当你在 Theia 上做二次开发时，可以关注的性能点
小结：别指望它像 React 一样“自动聪明”，但它给了你足够的控制力

Lumino 在视频编辑器等工具类应用中的可能性与想象

为什么一提视频编辑器，就容易想到 Lumino 这种框架？
用 Lumino 搭一个视频编辑器大致会怎么分层？
一些具体的 UI 例子：Lumino 能帮上哪些忙？
和 React/Vue 生态结合的想象
实际上有没有类似方向的项目？
小结：把 Lumino 当成“通用工具类应用壳”的一个选项

Lumino 的工具与基础设施模块：与 Lodash 的对比杂谈

先定个调：这是“框架内部基建”，不是“业务工具库”
@lumino/algorithm：一小撮“拿来就用”的算法积木
@lumino/collections：为框架准备的容器，而不是通用 Map/Set 替代品
@lumino/properties：给对象挂“扩展属性”的正规方式
@lumino/polling：比 setInterval 高一档的轮询封装
这些模块在整个 Lumino / Theia 里的角色
小结：什么时候该想起它们，而不是顺手就 Lodash 一把梭？

Monaco：前世今生与在 Theia 中的角色

Monaco 与 Theia：MonacoInit 与编辑器装配流程

从入口里的 MonacoInit.init(container) 说起
MonacoInit 负责的主要任务
Monaco 前端模块大致包含什么
从 EditorManager 一路走到 Monaco 编辑器实例
编辑器 Widget 如何落到 Lumino 布局里
小结：MonacoInit 把编辑器这一块“挂”进了 Theia 的骨架

Monaco 核心概念：Model / Editor / View 与 Theia 抽象

文本模型（ITextModel）：真正存放代码内容的地方
编辑器实例（IStandaloneCodeEditor）：操作模型的入口
一个 Model 可以挂多个 Editor
View 的角度：模型是数据，编辑器是视图 + 控制
小结：先牢牢记住“一个模型，多种视图”的图景

Monaco 语言与高亮：注册语言、Monarch 语法与 Theia 映射

注册一种语言的基本步骤
用 Monarch 定义语法高亮规则
主题如何把 token 映射为颜色
在 Theia 中语言注册的典型链路
与 LSP 和语言特性的结合
小结

Monaco 装饰器与标记：deltaDecorations、Gutter 与 Theia Markers

装饰器的基本概念
deltaDecorations：增量更新装饰器
常见装饰器选项
Theia 的 Markers 如何映射到装饰器
其它基于装饰器的功能
小结

Monaco 命令与操作：Editor Actions、快捷键与 Theia 命令系统

Editor Action：在编辑器上挂操作
快捷键与 Keybinding 配置
Theia 中的命令系统与 Monaco Action 的关系
两套命令系统的协同思路
小结

Monaco 的 diff 编辑器、多模型与大文件场景

diff 编辑器的基本用法
多模型并存：资源管理与标识
大文件场景：Monaco 的行为与限制
多模型 + 大文件下的一些注意点
小结

Monaco 性能与优化：渲染、事件与资源管理

渲染与布局：避免不必要的重排
事件风暴：谨慎处理变更与光标事件
装饰器数量：成千上万的标记也要有节制
多模型与资源管理：防止模型泄漏
大文件：功能与性能之间的取舍
小结

InversifyJS：Theia 架构的依赖注入基石

InversifyJS：依赖注入的前世今生（从工厂模式到 Theia）

一切从“直接 new 依赖”开始
手工构造 + 工厂模式：第一步解耦
Java 世界的答案：Spring / Guice / CDI 等 DI 容器
回到 JavaScript/TypeScript：为什么也需要 DI？
InversifyJS：把 Java 世界那套“DI 思维”搬到 TS 上
为什么 Theia 这么重度使用 InversifyJS？
小结：先有“为什么需要 DI”，才有“选 InversifyJS”

在项目中引入 InversifyJS：配置与依赖

安装依赖
TypeScript 配置：开启装饰器支持
引入 reflect-metadata
环境支持与 polyfills
- 必需特性
- 可选特性（仅在特定场景需要）
在 Theia 项目中的情况
常见问题排查

InversifyJS 基础示例：从传统依赖到依赖注入

代码解析：一步步理解依赖注入
这个例子说明了什么？
下一步：更复杂的场景

InversifyJS：服务标识符与接口绑定（Symbol 与接口）

服务标识符到底是干嘛用的？
为什么推荐用 Symbol 而不是字符串？
接口绑定：在类型层面隐藏实现细节
类作为标识符 vs Symbol 作为标识符
在 Theia 源码里可以怎么“练习找一找”？

用类本身作为服务标识符：简化绑定的另一种方式

类作为标识符的基本用法
使用 toSelf() 简化绑定
已知局限性：循环依赖的问题
在 Theia 里的实践建议
小结

InversifyJS：作用域与生命周期（Singleton / Transient 等）

三种常见作用域
在 Theia 里，哪些东西应该是单例？
哪些场景更适合 transient（每次一个新实例）？
生命周期与资源释放：和 disposable 的关系
在 Theia 源码里如何“感受”这些作用域？

InversifyJS：多种绑定方式（to / toSelf / toConstantValue / toDynamicValue / toFactory / toProvider）

1. to：最常见的“接口 → 实现类”绑定
2. toSelf：具体类自己就是标识符
3. toConstantValue：绑定常量/配置/单例对象
4. toDynamicValue：按需、惰性、基于上下文生成实例
5. toFactory：返回一个“工厂函数”
6. toProvider：支持异步创建（返回 Promise 的工厂）
小结：选哪种绑定，取决于“对象是谁创建的”和“何时创建”

InversifyJS：高级绑定（命名绑定、标签绑定、多重注入、可选注入）

命名绑定：一个接口，多种实现，用名字区分
- 注册阶段
- 注入阶段
标签绑定：用键值对来表达“这个实现的特性”
- 注册阶段
- 注入阶段
多重注入：一次性拿到“这一类所有实现”
- 注册阶段：正常多次 bind 即可
- 注入阶段：用 @multiInject
可选注入：这个依赖可能没有也没关系
在 Theia 里的影子

InversifyJS：ContainerModule 与模块化 DI（对标 Theia 前后端模块）

为什么需要 ContainerModule？单文件 bind() 太乱了
ContainerModule：把一组绑定封成一个模块
AsyncContainerModule：支持异步初始化的模块
对标 Theia：*-frontend-module / *-backend-module 本质上就是 ContainerModule
模块之间的依赖关系：松耦合的“功能拼图”
在自己项目里怎么设计模块粒度？
小结：ContainerModule 是把 DI 从“单文件配置”提升到“功能级别模块”的关键

InversifyJS：懒注入与循环依赖（lazyInject 的利与弊）

先回顾一下：循环依赖在 DI 容器里为什么麻烦？
inversify-inject-decorators 与 lazyInject
示例：用 lazyInject 缓解循环依赖
懒注入不是银弹：它解决的是“访问时机”，不是“设计问题”
在 Theia 这种架构里，应该怎么看待懒注入？
小结：把 lazyInject 当成“特例工具”，而不是日常注入方式

InversifyJS：测试中的容器用法（测试容器与 rebind）

两种基本策略：测试容器 vs 重绑定
建一个最小测试容器
在现有容器上用 rebind 替换实现
针对 Theia 的一些具体建议
一些实用的小技巧
小结：把容器当成“测试夹具”的一部分

InversifyJS 与 Theia：从 index.js 看前端启动与模块装配

这个 index.js 在 Theia 里扮演什么角色？
Container：Theia 前端世界的“装配厂”
container.load(module)：Theia 模块 = 一堆 InversifyJS 绑定
preload：在应用真正启动前做准备工作
最后一步：从容器拿出 FrontendApplication 并启动
这份 index.js 给我带来的几个 InversifyJS 认知

InversifyJS 与 Theia：概念对照表（从 DI 到扩展点）

总览：一张小表先看个大概
容器与模块：应用壳 + 功能拼图
服务标识符与接口：Symbol 作为“运行时接口名”
绑定方式：从简单服务到工厂/Provider
多实现与扩展点：multiInject 对应 Theia 的 Contribution 模式
作用域与生命周期：单例服务 vs 瞬时 Widget
懒注入、可选注入：特殊场景下的工具- InversifyJS：
容器在测试里的角色：测试夹具
最后一小节：一条“从 InversifyJS 到 Theia”的心智路径

LSP：语言服务器协议的前世今生与在 Theia 中的角色

LSP 协议核心与常见请求：从文档同步到补全诊断

消息结构与传输方式概览
初始化阶段：initialize / initialized
文档同步：didOpen / didChange / didSave / didClose
补全：textDocument/completion
悬停与跳转：hover / definition / references
诊断与问题列表：publishDiagnostics
小结

LSP 在 Theia 中的客户端架构：前端、后端与语言服务管理

角色分工概览
前端：LSP 客户端与编辑器的衔接
后端：语言服务器进程与连接管理
前后端之间的桥接：消息通道与文档路由
多语言与多 Language Server 管理
与依赖注入和扩展点的结合
小结

LSP 与 Monaco 的适配：诊断、补全与跳转在编辑器中的落地

诊断：从 publishDiagnostics 到 Markers 再到装饰器
补全：LSP completion 结果到 Monaco CompletionItem
悬停信息：hover 到悬浮气泡
跳转定义与引用：LSP definition/references 到编辑器导航
命令体系中的一环：从 Theia 命令到 LSP 请求再到 Monaco 行为
小结

LSP 最小示例：一个简单 Language Server 与 Theia 扩展示意

一个极简 Language Server 的骨架
在 Theia 中声明一个语言客户端贡献点
服务器如何被 Theia 启动
端到端效果会是什么样

LSP 多语言与多服务器管理：配置、路由与性能考虑

多语言支持的基本配置思路
语言到服务器的映射与路由
多服务器并存下的资源与生命周期管理
请求并发与响应性能
与工作区和文件系统的协同
小结

AST：语法树到底是什么，以及和日常开发有什么关系

AST：前端常见语法树工具链一览（TypeScript / Babel / ESLint / SWC）

几个常见名字先对上号
TypeScript AST：TS 项目里的“首选工具”
Babel / ESTree：JS 世界的“通用语法树语言”
ESLint：站在 AST 上的一层“规则框架”
SWC / esbuild：更偏构建方向的 AST

AST：TypeScript 编译器 API——从源码到语法树与简单分析

准备一个最小的 TS AST 实验环境
遍历 AST：找到所有函数声明
一个更实际一点的例子：找出所有 console.log
再往前一步：借助 TypeChecker 做简单类型分析
和 LSP / Theia 里的那套有什么关系？

AST：检测与自动修复——从规则到 CodeAction

一个最简单的检测规则：找出所有 var
生成修复后的代码
一个更实际的例子：检测未使用的导入
在 LSP CodeAction 里的落地
和 ESLint / Prettier 的关系
小结

AST 到编辑器 UI 的完整闭环：从语法树到 LSP 再到 Monaco

在 Language Server 里做 AST 分析
把 AST 分析结果转换成 LSP 协议格式
Theia 前端：接收 LSP 消息并适配到 Monaco
一个完整的流程示例
小结

AST：跨文件分析与项目级代码理解——从单文件到整个项目

从单文件到项目级：为什么需要跨文件分析
TypeScript Program：把多个文件的 AST 组织起来
符号表：从 AST 节点到跨文件的符号
查找所有引用：在整个项目里追踪符号
跨文件的导入/导出分析
在 Language Server 里的实际应用
- 维护项目状态
- 实现跨文件的 LSP 功能
性能考虑：增量更新与缓存
小结

AST：调试与可视化——从查看结构到开发工具链

最简单的调试：打印 AST 结构
使用 TypeScript Compiler API 的内置工具
AST Explorer：在线可视化工具
TypeScript AST Viewer
调试 AST 转换：打印前后对比
在 Language Server 里调试 AST
可视化 AST 的工具函数
在 Theia 里调试 Language Server
常见调试场景
小结

IDE 相关开发

IDE 中的 CSS 常见应用：布局、主题与交互细节

布局：从传统分栏到“桌面感”界面
主题与配色：暗色模式、语法高亮与状态色
交互细节：悬浮、拖拽、分屏与可折叠区域
滚动与“定位感”：代码区域的可读性增强
响应式与嵌入场景：不仅是桌面浏览器

AI IDE 中的 CSS 玩法：打字机效果、主动滚动与状态提示

打字机效果：流式生成时的“在场感”
模型状态与置信度的可视化
AI 相关面板的布局：侧边 Chat、内联气泡与悬浮卡片
小结：AI IDE 的 CSS 重点在“动态感”和“状态感”

VS Code 插件体系总览：Extension Host、激活事件与贡献点

VS Code 插件整体是怎么跑起来的？
插件的基本结构：package.json + 激活入口
- 1. package.json 里的扩展声明
- 2. 扩展代码里的 activate / deactivate
激活事件：插件不是一上来就全跑起来的
contributes：插件是通过哪些「扩展点」接入 VS Code 的？
插件、语言服务器和内置功能之间的关系
小结：理解 VS Code 插件体系的几个关键点

Theia 插件体系总览：前后端扩展、扩展点与 DI 容器

Theia 的整体分层：应用壳 + 前端扩展 + 后端扩展
扩展包结构：前端和后端模块如何被挂载？
DI 容器和扩展点：Theia 如何组织插件能力？
前端扩展：命令 / 菜单 / 快捷键 / 视图是怎么挂进壳里的？
后端扩展：服务、协议与前后端通信
Theia 插件与 VS Code 插件的对应关系（鸟瞰版）
小结：理解 Theia 插件体系要抓住的几个点

VS Code 与 Theia 插件模型对比：扩展点、架构与兼容性

架构分层对比：Extension Host vs 前端 / 后端扩展
扩展点声明方式：contributes vs 扩展点接口 + DI 绑定
- VS Code：package.json + contributes
- Theia：扩展点接口 + Inversify 绑定
命令 / 菜单 / 快捷键：两边的对照关系
自定义视图与编辑器增强：Webview / TreeView vs Lumino Widget / Monaco 集成
兼容性与复用：在 Theia 中跑 VS Code 插件意味着什么？
什么时候写 VS Code 插件，什么时候写 Theia 原生扩展？
小结：一张脑海里的对比图

VS Code 插件：命令、菜单与快捷键——从 contributes 到代码注册

命令是什么？和菜单、快捷键是什么关系？
在 package.json 里声明命令：contributes.commands
在代码里注册命令实现：vscode.commands.registerCommand
菜单：命令如何出现在右键菜单 / 标题栏等位置？
快捷键：为命令绑定按键组合
一条完整链路复盘：从 contributes 到最终触发
常见坑与实践建议

Theia 扩展：命令、菜单与快捷键——基于 Command 与 Keybinding 扩展点

Theia 里的命令系统负责什么？
CommandContribution：注册命令与行为
前端模块中的绑定：把贡献类接入 DI 容器
MenuContribution：把命令挂到菜单上
KeybindingContribution：为命令绑定快捷键
一条完整链路：Theia 中的命令 / 菜单 / 快捷键是如何协同的？
设计与实践上的一些建议

VS Code 插件：自定义视图——TreeView 与 Webview 典型场景

TreeView：结构化数据的「侧边栏树」
Webview：完全自定义的 HTML 视图
TreeView vs Webview：如何选择？
常见问题与实践建议

Theia 扩展：自定义视图——用 Lumino 与 ViewContribution 挂一个侧边栏面板

Theia 视图的大致结构：Widget + ViewContribution
第一步：实现一个简单的 Widget（或 ReactWidget）
第二步：用 ViewContribution 把 Widget 挂到侧边栏
第三步：在前端模块中绑定 Widget 与 ViewContribution
视图与命令/菜单/快捷键的协同
和 VS Code TreeView / Webview 的差异感知
小结：在 Theia 里挂一个侧边栏视图的心智模型

Theia：如何托管 VS Code 插件——plugin-ext-vscode 兼容层的架构与调用路径

总览：在 Theia 里再起一层 VS Code 风格的「插件宿主」
第一步：插件发现与 package.json 解析
第二步：vscode API 兼容层——把调用“导向” Theia 服务
第三步：激活与生命周期——仿真 VS Code 的 activationEvents
第四步：命令 / 菜单 / 视图等贡献点的「桥接」
第五步：前后端调用路径——从 VS Code API 到 Theia 服务
兼容性的边界与取舍
小结：一条可以在脑子里复现的调用路径

AI

OpenClaw

1. OpenClaw 为什么突然火起来

2.1 Agent Runtime（持续运行的 AI）
2.2 工具调用系统（Tool / Skills）
2.3 Memory 系统
2.4 多模型路由

RBAC 模型
OpenClaw 模型

Edict 的价值
Edict 的局限

6.1 Scaling（模型规模）
6.2 推理计算（test-time compute）
6.3 系统增强

1. 训练成本爆炸
2. benchmark 接近饱和
3. 推理能力瓶颈

Transformer 架构速览：从 Self-Attention 到 GPT

Self-Attention 细节：从矩阵形状到多头实现

输入输出长什么样？
Q / K / V 是怎么算出来的？
Scaled Dot-Product Attention 的矩阵形状
多头注意力：为什么要多一个 Head 维度？
Mask 是怎么加进去的？
工程上常见的几个实现细节

位置编码与长序列：从 Sinusoidal 到 RoPE

为什么 Self-Attention 需要位置？
正弦位置编码（Sinusoidal）在干什么？
可学习的位置编码（Learned Positional Embedding）
RoPE（Rotary Position Embedding）的直觉
长序列时的位置问题

Encoder/Decoder 与 GPT：结构和任务差异

原始 Transformer：Encoder-Decoder 结构
Encoder-only：BERT 一类偏“理解”的模型
Decoder-only：GPT 一类偏“生成”的模型
三类结构在任务上的差异（工程视角）
为什么现在 Decoder-only 这么流行？

Transformer 训练与推理细节：损失函数、Mask 与并行

训练目标：本质就是“预测下一个 token / 填空”
Mask 的两种核心用途：Padding 与 Causal
- Padding Mask：不要让补零影响注意力
- Causal Mask：不能偷看未来
训练时的并行性：为什么 Transformer 跑得快？
推理阶段：KV Cache 带来的巨大加速
精度与稳定性：FP16 / BF16、梯度裁剪与规范化
小结：训练/推理中的关键点

大规模 Transformer：参数规模、并行与内存优化

参数规模与显存：大概是个什么量级？
并行方式：Data / Model / Pipeline
内存优化：激活检查点、ZeRO 等
- 激活检查点（Activation Checkpointing）
- ZeRO：分解优化器状态和梯度
精度和算子融合：再往下挖一点性能
推理场景：批量、并发与延迟的权衡
总结：规模化背后的一些关键点

轻量微调与 LoRA：在小显存上用大模型

全参微调：效果最好，但最昂贵
冻结主干 + 小头微调：最简单的 Parameter-Efficient Tuning
LoRA 的直觉：只学“一个低秩残差”
LoRA 在代码层面大概长什么样？
Prefix / Prompt Tuning：不改模型，只改输入
组合与实践：LoRA + 微调头部
什么时候选哪种方案？

工程应用视角：从云端 API 到本地部署

云端 API：最低门槛的接入方式
混合架构：在线 API + 离线 / 预计算
本地推理：什么时候值得把模型“搬进来”？
前端与边缘：在“离用户最近的地方”用 Transformer
监控与评估：不能只看“感觉还不错”
安全与权限：模型不是“通用大脑”

模型微调：从决策到上线

微调第一问：什么时候该调，什么时候做 RAG

微调到底在改什么？
为什么很多场景更适合先做 RAG？
什么时候微调是顺理成章的？
一个常见误区：把微调当知识库
一个够用的决策树（可直接套用）
- 第一步：先看要不要“现在就做微调”（Q3/Q4）
- 第二步：在可做微调的前提下，用 Q1/Q2 选路线
小结：先判定问题类型，再选技术手段

SFT 与 LoRA：数据、训练与验证最小闭环

先看方法分工：SFT 与 LoRA 是什么关系？
为什么 LoRA 在工程里这么常见？
数据集怎么做才“像工程资产”？
训练前先定义“要赢在哪里”
一个最小可用训练闭环
常见坑：只看训练损失，不看任务指标
小结：微调不是“跑个脚本”，而是一个可验证过程

微调上线：评测、灰度、回滚与持续迭代

为什么“离线好看”不等于“线上可用”？
评测分层：离线、灰度、全量
灰度发布：先控制风险，再追效果
回滚策略：上线前就要准备好
badcase 回流：把错误变成训练资产
迭代节奏：小步快跑比大版本突进更稳
小结：微调真正的价值在于“可持续变好”

AI 微调成本核算：一张表算清训练与维护投入

先统一口径：你在算的不是“训练一次多少钱”
一个够用的成本模型（先算月度）
成本拆解（一）：算力成本怎么估
成本拆解（二）：数据成本通常比想象更高
成本拆解（三）：人力与协同成本
成本拆解（四）：上线后维护是长期项
一张可直接套用的估算表
怎么判断“值不值”？
小结：成本核算的核心是“可比较”

IDE 中的 AI：从 LSP 到智能助手的演进

现代代码补全的技术路线：从 LSP 到大模型补全

早期补全：符号表 + 模板的年代
LSP 补全：真正“语法/类型感知”的补全
大模型补全：从“列出选项”变成“生成一段逻辑”
LSP 与大模型补全的协同与分工
上下文构造：让补全“刚好知道够多”
Post-process 与“最后一道防线”
对使用者意味着什么？

上下文构建与代码索引：让模型只看该看的东西

为什么“上下文选择”比模型本身还重要？
第一层筛选：基于编辑器状态的“近场上下文”
第二层筛选：基于语义和结构的项目级索引
切块策略：按什么粒度把代码喂给索引？
构造检索查询：不是简单把选中代码塞进去
Prompt 结构：如何把上下文拼装给模型？
截断与压缩：在有限窗口里做取舍
和日常编码体验的连接

Claude 与 Cursor 风格 IDE 助手：一个可能的架构拆解

整体视角：客户端插件 + 后端服务 + 模型层
客户端插件：它知道你“正在干什么”
后端的编排：从请求到模型调用之间发生了什么？
代码索引服务：让“看全项目”变成可能
Diff / Patch 流程：从自然语言建议到实际改动
安全与隐私：文件访问与数据出境的边界
和你日常使用体验的对照

在自己 IDE 里接一个最小 AI 助手：一条可行链路

先定义“最小可用”的目标
第一步：在 IDE 里塞一个“对话入口”
第二步：在后端做一个简单的 LLM 代理
第三步：把“解释/建议”做顺手，再考虑自动修改
第四步：接入一个最简单的索引，让助手不只看当前文件
第五步：把测试、构建等工具挂进助手的“工具箱”
总结：一条不那么吓人的落地路径

IDE 中的安全：隐私与幻觉治理

源码隐私：模型眼里的“上下文”其实就是你的仓库
文件访问控制：不要默认“整个仓库都给模型看”
数据出境与合规：不只是技术问题
幻觉问题：模型说得很像真话，但可能是错的
用 LSP/编译器/测试做“事实校验”
对用户的反馈与教育：让开发者知道“该信哪一层”
小结：把 AI 助手当成组件，而不是“全能大脑”

企业级 AI IDE 设计总览：分层架构与关键数据流

分层架构：壳、语言服务、AI 编排、模型与索引
关键数据流：从 IDE 事件到模型再到补丁
为什么一定要有一个“AI 编排层”？
不同部署模式下的形态：本地 vs 云端 vs 混合
回到那个问题：企业级 AI IDE 核心关注什么？

Inline Chat 与 IDE 集成：从选中代码到 Diff 应用

能力边界：Inline Chat 要解决什么，不解决什么？
从 IDE 出发：如何打包一次 Inline Chat 请求？
编排层处理：确定上下文与输出格式
Prompt 结构：给模型的输入长什么样？
Diff 解析与应用：如何保证“不乱改”？
与多文件重构的边界：Inline Chat 何时应该“跳”到另一条管线？
小结：一条“从选中到 Diff 应用”的清晰链路

上下文构建与 Token 成本控制：企业级策略

为什么要把“Token 成本”当成一等公民？
上下文的三层结构：核心 / 相关 / 附加信息
动态裁剪：按任务类型分配 Token 预算
优先级拼接：谁先占坑，谁后被裁
上下文缓存：不要为同一块信息重复买单
观测与策略迭代：先量出来，再优化
和上下文构建结合起来看那几个问题

多文件重构管线：从 LSP 分析到安全 Diff 应用

场景定义：什么算“多文件重构”？
第一步：用 LSP 和索引找出“影响面”
第二步：构造多文件重构任务的上下文
第三步：生成并解析跨文件 patch
第四步：IDE 中的多文件 Diff 体验
第五步：安全策略与回滚
和 Inline Chat 的关系：两条互补的管线

项目级 RAG 与大仓库优化：索引、召回与错误控制

什么是项目级 RAG，在 IDE 里要解决什么？
索引层：符号 + 结构 + 向量
切块与元数据：RAG 的基础工程
大仓库优化：分层索引与增量更新
召回策略：如何减少“错误召回”？
与 Token 成本控制的结合
小结：项目级 RAG 是“项目记忆层”，不是“万能大脑”

LSP 在 AI IDE 中的角色：事实引擎、切块助手与安全网

传统角色回顾：LSP 原本在 IDE 里做什么？
角色一：事实引擎（Fact Engine）
角色二：切块助手（Chunking Assistant）
角色三：安全网（Safety Net）
LSP 与 AI 的协作模式：谁主谁辅？
回答那个问题：LSP 在 AI IDE 里如何配合？

工具调用与安全沙箱：让模型能做事但做不坏

为什么要给模型一套“工具箱”？
工具抽象：统一描述“能做什么”和“会带来什么后果”
调用模式：ReAct 风格 vs 固定流程
安全沙箱：限制模型“能碰到什么”
有副作用的操作：永远需要“人类在环”
审计与回滚：为“出了问题”预先准备
小结：工具调用是“能力放大器”，不是“权力下放”

评估、监控与迭代体系：AI IDE 的工程生命线

为什么 AI IDE 更需要可观测性？
在线指标：从使用情况看“有没人用、敢不敢用”
离线评估：复盘真实开发会话
A/B 实验与灰度发布：不要“一刀切”上/下线能力
错误与异常的治理：从“失败”里学东西
用户反馈与人工评审：人仍然是评估环节的一部分
小结：把 AI IDE 当成一个“持续优化的产品”，而不是“一次性接入的能力”

LangChain

LangChain：到底在工程里解决了什么问题？——模块拆解与使用边界

1. 如果不用 LangChain，工程里会长成什么样？
2. 核心模块一览：LangChain 把问题拆成了哪些块？
3. PromptTemplate 与 OutputParser：从「堆字符串」到「结构化 IO」
4. 知识与检索：RAG 管线从临时脚本变成可复用模块
5. 工具与 Agent：把「调用外部能力」变成一等公民
6. Runnable / LCEL：把「链」变成可读、可插桩的表达式
7. 什么时候用 LangChain，什么时候自己撸？
8. 小结：把 LangChain 放回「工程工具箱」的正确位置

LangChain 向量数据库选型：ObjectBox、ZVEC、Qdrant、Milvus 对比

1. 先统一一个选型视角：不是比功能最多，而是比匹配度
2. ObjectBox：偏本地嵌入式的轻量方案
3. ZVEC：按轻量向量引擎路线看待
4. Qdrant：服务化友好，过滤与检索能力平衡较好
5. Milvus：偏大规模分布式与高吞吐场景
6. 放到 LangChain 里看：集成层怎么设计更稳妥？
7. 一个务实的选型路径（按阶段）
8. 小结：把向量库当作「可替换基础设施」

LangChain：PromptTemplate 与 OutputParser——从堆字符串到结构化 IO

1. 直接堆字符串有什么问题？
2. PromptTemplate：把 prompt 拆成模板 + 变量
- 2.1 抽象出的核心概念
- 2.2 工程视角下的使用方式
3. OutputParser：把不稳定输出变成稳定结构
- 3.1 为什么要单独有一个 Parser？
- 3.2 工程上的几个直接收益
4. PromptTemplate + OutputParser：把一次调用看成「有签名的函数」
5. 使用这些抽象时需要注意的边界
6. 小结：为什么先从这两个模块讲 LangChain？

LangChain：工具调用与 Agent——从 Tool 抽象到安全边界

1. 为什么需要「工具调用」这层抽象？
2. Tool 抽象：把外部能力变成可以被选择的「动作」
3. Agent 的角色：让模型学会「选工具 + 多步决策」
4. 安全边界：让模型「能做事但做不坏」
5. 工具调用不一定非要用 Agent
6. 小结：如何在工程里稳妥用好 Tool 与 Agent？

LangChain：RAG 与检索管线——从 Loader 到 Retriever 的拼装思路

1. RAG 的最小闭环：从「一堆文档」到「一段回答」
2. Loader：把各种数据源抽象成「文档流」
- 2.1 Loader 的角色
- 2.2 工程实践中的要点
3. Splitter：决定「一个文档切成多大一块」
- 3.1 为什么需要切分？
- 3.2 不同切分策略的影响
4. VectorStore：向量存储的抽象层
- 4.1 向量库差异不应该渗透到业务里
- 4.2 工程实践中的常见模式
5. Retriever：把「怎么取文档」独立出来
- 5.1 Retriever 与 VectorStore 的关系
- 5.2 抽象的意义
6. 把 Loader / Splitter / VectorStore / Retriever 串起来
7. 常见坑与工程建议
8. 小结：RAG 在 LangChain 里的定位

LangChain：Runnable 与 LCEL——把多步链路写成可读表达式

1. 多步链路如果不用 LCEL，会长成什么样？
2. Runnable：把每一步都看成「可组合的算子」
3. LCEL：用表达式把 Runnable 串成「可读的链」
4. 观测：在链上的任何节点插钩子
5. 在工程里，用 LCEL 描述链路时需要注意什么？
6. 小结：为什么在 LangChain 里要关心 Runnable / LCEL？

LangChain vs 自己撸框架：选择与组合策略

1. 看清楚「多大一把锤子」在手里
2. LangChain 带来的几个主要收益
3. 可能带来的代价与约束
4. 适合优先用 LangChain 的场景
5. 适合先自己撸一层轻量封装的场景
6. 一种折中的「组合策略」
7. 小结：不是二选一，而是找到合适的分层

Backend

Node.js：服务端与工具运行时

Node.js 运行时心智：事件循环、libuv 与非阻塞 I/O

Node.js 是什么：不是语言，是一套运行时
单线程指的是什么，又不指的是什么
libuv：事件循环与线程池的粘合层
事件循环：粗略阶段（够用即可）
非阻塞 I/O 在代码里长什么样
和浏览器事件循环的异同（一句话版）
小结：先把运行时模型立住

Node.js 模块与工程：CommonJS、ESM 与包边界

CommonJS：require / module.exports 的心智模型
ESM：import / export 与静态结构
package.json：不只是依赖列表，更是「契约」
node_modules 与解析规则：为什么「装得上」不等于「引得着」
CJS 与 ESM 混用：减少痛苦的几种策略
小结：模块是工程边界，不是语法糖

Node.js Stream 与背压：大文件与 HTTP 场景

为什么需要 Stream：内存与时间的折中
四类 Stream：读、写、双工、转换
pipe：连接流，并把背压传回去
大文件：createReadStream / createWriteStream
HTTP：请求与响应也是流
常见坑：同步、全量缓冲、错误处理
小结：Stream 是 Node I/O 的默认语言

Node.js 调试与观测：Inspector、日志与性能剖析

调试器：Inspector 协议与「能停住」的价值
console 与日志：够用、但要分层
错误与未捕获异常：别让它悄悄退出
性能剖析：先分清 CPU、I/O 与事件循环
诊断报告：heap snapshot 与内存泄漏
小结：观测是闭环，不是「多打几行 log」

Node.js HTTP 服务：内置 http 模块与请求响应心智

http.createServer：回调里有什么
请求行、头、体：顺序与边界
Server 与 TCP：监听、并发与 backlog
HTTPS：TLS 终止放在哪
和「框架」的关系：中间件在干什么
常见坑：响应没 end、体没读完、错误没处理
小结：http 是骨架，框架是肌腱

Node.js 进程与子进程：child_process、cluster 与 worker_threads

process：当前进程的环境与控制台
child_process：新进程、新 V8、隔离最强
worker_threads：共享 ArrayBuffer，更像「并行 JS」
cluster：多进程吃满多核，外加调度
选型时别混在一起：先问「瓶颈在哪」
小结：隔离与并行都有代价

Node.js 包管理与脚本：npm、lockfile 与 monorepo 心智

npm / yarn / pnpm：同一套生态，不同的「放包方式」
dependencies 与 devDependencies：运行时与工具链
lockfile：可复现构建的底线
scripts：npm 作为「小 Makefile」
workspace 与 monorepo：包与包之间的关系
小结：包管理是「契约 + 可复现」

Node.js 测试与 mock：单元测试与模块边界

测试金字塔在 Node 里的一句话版
断言异步：Promise、async/await 与计时
mock：替换的是「边界」，不是「偷懒」
模块替换与 ESM：比 CJS 更「硬」
测试数据与夹具：fixture、工厂与快照
小结：好测试保护重构，而不是锁死实现

Node.js 安全与依赖：审计、密钥与供应链

依赖即攻击面：为什么「只写业务代码」不够
npm audit / 扫描工具：信号，不是判决书
最小权限：运行时、文件、网络
密钥：别进仓库，别进前端 bundle
依赖治理：固定、审查与私有源
小结：安全是「默认就紧」+「出事能追」

Node.js 文件系统与 path：fs API 与路径心智

路径是字符串，但「怎么拼」不是小事
fs：回调、fs.promises 与同步 API
目录遍历与递归：别在热路径上无脑递归
fs.watch / watchFile：开发体验 vs 跨平台
权限与标志位：0644、可执行与 fs.constants
小结：文件操作 = 路径正确 + API 层级正确 + 并发意识

Node.js Buffer 与编码：二进制与字符集

Buffer 是什么：固定长度的字节序列
字符串 ↔ Buffer：编码必须心里有数
切片与拷贝：subarray、引用与 Buffer.alloc
与 Stream：Readable 里流出来的是什么
TypedArray、DataView 与 WASM
小结：字节不是「另一种字符串」

Node.js 网络层：Socket、TCP 与 UDP 心智

net：在操作系统 socket 上包一层
TCP 字节流：粘包、半包、要自己定界
net.connect / Socket：客户端长连接
UDP：dgram 与「消息」边界
和 HTTP / WebSocket 的关系
小结：先会字节流，再谈业务协议

Node.js 加密与 crypto：哈希、签名与密钥物料

哈希（digest）：完整性校验，不是加密
HMAC：共享密钥下的「认证 + 完整性」
对称加密（AES 等）：同一密钥加解密
非对称：公钥加密、私钥签名
随机数：randomBytes 与 Math.random
小结：先问目标，再选工具

Node.js 定时器与调度：setTimeout、setImmediate 与队列心智

setTimeout / setInterval：延迟与周期
setImmediate：本轮 I/O 后尽快跑
process.nextTick：高优先级「插队」
ref 与 unref：别让定时器拖住进程退出
与 Promise 微任务：顺序别混着赌
小结：定时器是「时间 + 事件循环」的合约

Node.js 生产运行：优雅退出、信号与 twelve-factor 心智

进程不是「永动机」：会收到结束信号
HTTP Server 的 close：不再 accept，尽量排完队
健康检查：liveness 与 readiness
twelve-factor 里和 Node 最贴的几条
崩溃与重启：退出码与「让它挂」
小结：生产运行 = 可观测 + 可替换 + 可体面收场

Node.js 压缩与 zlib：gzip、brotli 与流式管线

为什么在应用里还会碰 zlib
gzip / deflate / brotli：选型一句话
流式：createGzip 接到 pipe / pipeline
一次性 API：小 payload 用
与 HTTP：谁来设 Content-Encoding
小结：压缩是「算力换带宽」

Node.js CLI 与 readline：交互脚本与 REPL

从 process.argv 到「像样的 CLI」
stdin / stdout / stderr：管道与 TTY
readline：问答式、逐行日志处理
REPL：node 不加脚本时
shebang 与可执行文件：#!/usr/bin/env node
小结：CLI 也是「产品」

Node.js 错误与异常：可恢复边界与错误码

Error 对象：message、stack 与 code
操作类 vs 程序类：心智上的两条线
Promise 与 async：拒绝要「有主」
AggregateError：一次失败里包多个原因
与框架：错误到状态码的映射表
小结：错误是契约的一部分

DataBase

PostgreSQL

PostgreSQL Docker 启动

docker-compose

Windows PostgreSQL 使用

添加 bin 到环境变量之中
角色 "postgres" 不存在

Linux

Docker

Docker compose install

面试

前端一面：知识点与常见题整理

JavaScript 一面：作用域、闭包与 this 指向

作用域与作用域链
闭包：从定义到常见考点
this 指向：和作用域不是一回事
箭头函数的 this：从外层捕获
常见 this 题：用几条规则快速判断
常见面试题与参考答案
小结：一面回答时可以怎么组织？

JavaScript 一面：原型链、继承与 instanceof

原型对象与原型链：先把那几根箭头理清楚
instanceof 的原理：看右边 prototype 在不在左边的原型链上
手写继承：从 ES5 到 class 的几种常见写法
原型链相关的常见一面题
常见面试题与参考答案
和工程实践的连接：为什么还要关心原型？
小结：一面里如何自然地讲“原型链”？

JavaScript 一面：事件循环、宏任务、微任务与 async/await

事件循环的基本模型
Promise 与微任务：为什么总是“先 Promise 再 Timeout”？
async/await 底层仍然是 Promise + 微任务
一个稍微复杂一点的例子
几个一面经常会问到的小问题
常见面试题与参考答案
小结：一面时可以怎么讲？

JavaScript 一面：Promise、async/await 与常见手写题

Promise 基础：状态、then 链与错误传递
async/await：语法糖 + try/catch 错误处理
常见手写题之一：实现一个简化版 Promise.all
常见手写题之二：串行执行一组 Promise（限制并发为 1）
常见手写题之三：实现带并发限制的请求调度器
常见面试题与参考答案

JavaScript 一面：call / apply / bind 用法与区别

它们到底在解决什么问题？
call / apply / bind 的核心区别（一句话版）
call：改 this + 立即执行（参数逐个传）
- 1. 基本用法
- 2. 面试里常见问法
apply：改 this + 立即执行（参数数组传）
bind：改 this + 返回新函数（柯里化常用工具）
常见题型：手写 bind / call / apply 思路
- 1. 手写 call 的核心思路
- 2. 手写 bind 的核心思路
典型场景题：this、事件、回调里的用法
- 1. 「如何在回调里保证 this 指向某个对象？」
- 2. 「如何借用别的对象的方法？」
小结：一面里如何讲清 call / apply / bind？

前端一面：从输入 URL 到页面渲染，面试官到底想听啥

一面期望的“粒度”和结构
阶段一：网络请求的高层流程
阶段二：HTML 解析与资源发现
阶段三：从 DOM/CSSOM 到 Render Tree、Layout 和 Paint
阶段四：JavaScript 执行与对渲染的影响
常见面试题与参考答案

前端一面：HTTP 缓存、本地存储与跨域基础

HTTP 缓存：强缓存与协商缓存
本地存储：Cookie、localStorage、sessionStorage、IndexedDB
同源策略与跨域基础
- CORS（跨源资源共享）
- 其它跨域手段（了解即可）
常见面试题与参考答案

前端一面：前端安全基础（XSS 与 CSRF）

XSS（跨站脚本攻击）：把恶意脚本“塞进你的页面”
- XSS 的常见防御手段
CSRF（跨站请求伪造）：利用“浏览器自动带 Cookie”
- CSRF 的常见防御手段
常见面试题与参考答案

前端一面：盒模型、BFC 与经典布局题

盒模型：内容、内边距、边框和外边距
BFC（块级格式化上下文）：一个“独立的小布局世界”
经典布局题：水平居中、垂直居中、两栏/三栏布局
常见面试题与参考答案

前端一面：CSS 优先级、选择器与样式冲突排查

CSS 优先级的基本规则
常见选择器与易错点
样式冲突排查的常用思路
常见面试题与参考答案

前端一面：CSS 动效——transition 与 animation 常见考点

transition 和 animation 本质上有什么区别？
transition：核心属性与常见踩坑
animation：关键帧 + 控制参数
什么时候用 transition，什么时候用 animation？
面试里常见的延伸问题
小结：如何在一面里讲清楚 CSS 动效？

前端一面：DOM 事件流、事件委托与常见坑

事件流的三个阶段：捕获、目标、冒泡
事件委托：把监听器挂在父元素上
常见坑：阻止冒泡、阻止默认行为与 this/target 区分
常见面试题与参考答案
小结：事件相关题目更看重“过程讲解”而不只是结果

前端一面：防抖、节流与高频事件优化

高频事件的问题：scroll、resize、input、mousemove
防抖（Debounce）：只在“最后一次”触发后执行
节流（Throttle）：在一段时间内最多执行一次
常见手写：简单版本的防抖和节流
- 防抖函数（简化版）
- 节流函数（时间戳版本）
常见面试题与参考答案

前端一面：并发控制、重试与轮询题目精讲

并发限制：同一时间最多跑 N 个请求
请求重试：失败后按一定策略再试几次
轮询：定期请求直到满足条件或超时
常见面试题与参考答案

前端一面：加载与运行时性能优化核心思路

加载阶段：让页面“尽快可用”
运行时阶段：让交互“顺滑不卡顿”
常见面试题与参考答案

前端一面：打包、模块化与 Tree-Shaking 考点

模块化：ESM vs CommonJS
打包工具在做什么？（以 Webpack/Vite 为例）
Tree-Shaking：消除死代码的前提和局限
常见面试题与参考答案

前端一面：Web Worker 与 Service Worker——多线程与离线缓存核心考点

浏览器为什么需要 Worker？
Web Worker：把计算从主线程挪出去
- Web Worker 是什么？
- Web Worker 的基本使用模型
Service Worker：站在网络与页面之间的「中间层」
- Service Worker 是什么？
- Service Worker 的几个关键特征
Web Worker 和 Service Worker 有什么区别？
常见面试题：怎么围绕 Worker 展开回答？
答题小结：如何在一面里讲清楚 Worker？

React 一面：组件通信、列表 key 与表单处理

组件通信：从 props 到 Context
列表渲染与 key：为什么一定要 key？
表单处理：受控组件 vs 非受控组件
常见面试题与参考答案

React 一面：Hooks 常见考点（useState/useEffect 与自定义 Hook）

Hooks 的基本规则（常见概念题）
useState：异步更新与批量更新
useEffect：依赖数组、清理函数与常见 bug
自定义 Hook：复用逻辑而不是复用 JSX
常见面试题与参考答案

React 一面：生命周期——从 class 到 Hooks 与常见面试题

React 生命周期到底在解决什么问题？
class 组件视角：生命周期时间轴长什么样？
Hooks 视角：生命周期是怎么被拆解的？
几个高频面试题：生命周期怎么答更清楚？
生命周期相关的「陷阱题」与答题建议
小结：怎么在面试里讲清楚 React 生命周期？

前端一面：错误处理与全局异常捕获

同步与异步错误处理
全局异常捕获：onerror 与 unhandledrejection
框架中的错误处理：以 React 为例
常见面试题与参考答案

前端一面：前端监控与埋点系统设计

我们要监控和埋点什么？
采集方式：埋点 SDK 与全局 Hook
上报策略：实时 vs 批量、可靠 vs 开销
后端与可视化（简单提纲即可）
常见面试题与参考答案

前端一面：高频手写题（深拷贝、发布订阅与 LRU 缓存）

深拷贝：浅拷贝 vs 深拷贝 & 一个够用的实现
发布订阅（Pub/Sub）：解耦事件发送者与监听者
LRU 缓存：最近最少使用淘汰
常见面试题与参考答案

面试复盘：复盘面试经历与迭代打法

Leader面：一次离奇但有趣的面试

AI 一面：Agent 系统设计题

AI 一面：Agent 系统设计 19 问（逻辑结构与分条回答）

先立住总结构：这 19 题到底在考什么
心智模型：三条主线
分条回答（1-10）
分条回答（11-19）
小结：一面里最该展示的不是“知道多少名词”

TypeScript

TypeScript 高级类型：联合、交叉、字面量类型与类型守卫
TypeScript 泛型：从基础到进阶
TypeScript 类型操作：类型推断、断言、收窄与兼容性
TypeScript 类与接口：面向对象编程
TypeScript 工具类型：内置工具类型详解
TypeScript 模块与命名空间
TypeScript 装饰器与元数据
TypeScript 配置与工程化
TypeScript 实战：常见模式与最佳实践

© 2026