背景 大表格卡顿通常来自渲染数量、响应式开销或频繁派生计算。先区分瓶颈，再决定虚拟列表、分页还是数据模型调整。 核心判断 只渲染可见窗口并保留适当 overscan。 对不可变大数组使用 shallowRef，替换数组触发更新。 行 key 稳定，昂贵格式化与计算按实际依赖缓存。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 const rows = shallowRef<Row[]>([]); const visibleRows = computed(() => rows.value.slice(start.value, end.value)); 边界与误区 切片只是虚拟列表的局部逻辑，还要维护滚动占位、行高和焦点。shallowRef 的深层原地修改不会自动更新，必须遵守不可变替换约定。 验证方式 在目标移动设备测试大数据滚动、排序和选中状态；记录长任务与内存，同时验证键盘导航、可访问性和屏幕尺寸变化。 小结 使用虚拟列表、稳定 key 和服务端筛选，避免把整份深层对象传给每个单元格。
背景 请求成功时才有 data，失败时才有 error。这种关联如果只靠可选字段表达，调用方很容易忘记判定状态。 核心判断 每个分支使用唯一字面量作为判别字段。 switch 分支内使用对应数据，让编译器完成收窄。 用 never 做穷尽检查，新增状态时迫使消费者同步处理。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 type Result<T> = { status: "loading" } | { status: "ok"; data: T } | { status: "failed"; error: Error }; 边界与误区 可辨识联合只约束编译期代码，不能证明 HTTP 返回的 JSON 符合声明。不要在最后用类型断言绕过穷尽检查。 验证方式 增加一个 cancelled 状态，确认遗漏的消费者编译失败；边界输入单独做运行时校验，测试不合法状态与缺失字段。 小结 为每种状态定义唯一字面量字段，让编译器阻止 loading、error、data 的错误组合。
背景与问题界定 在线PDF渲染预览服务的核心需求是在浏览器端完成PCLm格式转换和页面渲染，避免每次预览都请求后端服务——既节省带宽，又能实现离线支持。初始方案使用JavaScript + PDF.js完成渲染，但在处理复杂PCLm光栅化指令（每英寸1200dpi的绘图命令）时性能急剧下降，单页渲染时间超过800ms。我们决定将核心图形引擎用Rust编写，编译为WebAssembly运行在浏览器中。但Rust到Wasm的链路并不像官方教程展示的那样平坦——wasm-bindgen的序列化开销、wasm-pack的模块化配置、包体大小与加载的权衡、以及与JavaScript宿主环境的互操作优化都需要在真实场景中打磨。 目标拆解与工程约束 数据传递零拷贝：PCLm数据流经过Zip解压后通常为2-8MB。通过wasm-bindgen的JSValue传递这个数据会触发两次拷贝（wasm→JS heap→wasm）。必须通过wasm-bindgen的Memory直接操作线形内存，或使用SharedArrayBuffer实现真正的零拷贝传递。 Wasm包体控制：Rust标准库的panic处理、格式化输出等infrastructure代码会增加30-50KB的wasm文件大小。对于加载时间敏感的场景，需要精细控制wasm-opt优化级别并启用wee_alloc或dlmalloc替代默认分配器。 JavaScript与Wasm的异步协同：Rust端执行长时间渲染操作时会阻塞主线程，导致UI冻结。需要将计算量大的渲染任务分割成chunk，使用requestAnimationFrame或Web Workers调度，并将结果通过wasm-bindgen的Closure和Promise机制回传给UI层。 跨线程安全与共享内存：在未来升级中，我们希望利用多核并行渲染多个PDF页面。WebAssembly的共享内存（--target web + SharedArrayBuffer）使得cooperative多线程可行，但Rust的std::thread在wasm目标中不可用，需要使用wasm-bindgen-rayon构建work-stealing线程池。 方案设计 我们采用三层架构。第一层是"核心Wasm模块"——纯Rust库（#![no_std] + alloc），包含PCLm解析、Path光栅化、颜色空间转换等算法。这一层不依赖任何wasm-bindgen导入，保持纯计算逻辑的可测试性和可复用性。第二层是"绑定层"——通过wasm-bindgen暴露FFI函数给JavaScript，管理从JS侧接收的原始字节缓冲区（通过Uint8Array到Vec<u8>的零拷贝映射），将计算结果以共享内存形式暴露给JS。第三层是"宿主层"——TypeScript封装，负责调用Wasm函数、将渲染结果blit到Canvas、处理worker调度。 // Rust端（绑定层） #[wasm_bindgen] pub struct PclmEngine { engine: core::PclmEngine, } #[wasm_bindgen] impl PclmEngine { #[wasm_bindgen(constructor)] pub fn new(dpi: u32) -> Result<PclmEngine, JsValue> { console_error_panic_hook::set_once(); Ok(PclmEngine { engine: core::PclmEngine::new(dpi), }) } #[wasm_bindgen] pub fn render_chunk(&mut self, input: &[u8], page: u32) -> Result<Vec<u8>, JsValue> { // input是JS侧Uint8Array的直接引用，零拷贝传递 self.engine.render_page(input, page) .map_err(|e| JsValue::from_str(&e.to_string())) } } 关键的零拷贝技巧：&[u8]作为参数接收JavaScript的Uint8Array（通过wasm-bindgen的借用语义实现指针共享），返回Vec<u8>则为JS分配新的ArrayBuffer。对于大批量输出（如渲染后的RGBA像素buffer），我们使用预先分配的固定大小的JsValue缓冲区，避免每次渲染都做malloc和memcpy。 ...
背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 const state = reactive({ loading: false }) 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。
背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 const state = reactive({ loading: false }) 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。
背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 const state = reactive({ loading: false }) 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。
背景 后台系统里最难维护的页面之一，就是大表单： 字段多 联动多 校验规则多 草稿和提交逻辑分叉 如果状态设计不清晰，后期改一个字段就会牵动全局。 实用拆分 表单值与 UI 状态分离 同步校验与异步校验分离 页面状态按分区拆 composable const formValue = reactive({ name: '', email: '', company: '', }) const uiState = reactive({ submitting: false, dirty: false, activeTab: 'basic', }) 防止无效重渲染 大对象不要全量深监听 使用按字段 watch 拆分子组件隔离更新范围 watch( [() => formValue.email, () => formValue.company], () => { validateContactFields() } ) 总结 大表单的关键不是“怎么写更快”，而是“怎么改不炸”。 前期做好状态边界，后期迭代成本会低很多。 复杂页面最终拼的是可维护性，不是首版速度。
背景 Vue3 发布两年多了，从 Options API 迁移到 Composition API 的项目也有了不少。这里总结一些实战经验。 为什么需要 Composition API Options API 的问题：逻辑关注点分散在一个组件的各个选项里（data、methods、computed、watch…）。 // Options API - 逻辑分散 export default { data() { return { count: 0 } }, methods: { increment() { this.count++ } }, computed: { doubled() { return this.count * 2 } }, watch: { count(newVal) { console.log('count changed:', newVal) } } } <!-- Composition API - 逻辑内聚 --> <script setup> import { ref, computed, watch } from 'vue' const count = ref(0) const doubled = computed(() => count.value * 2) const increment = () => count.value++ watch(count, (newVal) => { console.log('count changed:', newVal) }) </script> 实用技巧 1. ref vs reactive 该用哪个？ // primitive types (String, Number, Boolean) -> ref const name = ref('BvBeJ') const age = ref(18) // objects/arrays -> reactive const user = reactive({ name: 'BvBeJ', skills: ['Go', 'Rust', 'C++'] }) // 或者对象也用 ref，通过 .value 访问 const user = ref({ name: 'BvBeJ' }) user.value.name = 'New Name' // 需要 .value 我的习惯： 简单类型用 ref，复杂对象用 reactive。TypeScript 类型推导更清晰。 ...