从「一口气渲染到底」到「可中断的渲染」
两个阶段：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 库的关系
小结

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 原生扩展？
小结：一张脑海里的对比图