102 posts tagged with "全栈开发"

Electron 的本质是两个不同类型的进程，IPC 是它们之间唯一合法沟通的桥。

1. 进程模型：一个 main 进程（Node.js 全权限）+ N 个 renderer 进程（Chromium 受限沙箱）
2. IPC 核心：main 用 ipcMain 监听，renderer 用 ipcRenderer 发起，contextBridge 是安全转交
3. 三种调用模式：send/on（单向）、invoke/handle（异步返回值）、MessagePort（双向长连接）
4. 安全铁律：默认开 contextIsolation + nodeIntegration: false，主进程做权限守门人
5. 反模式：在 renderer 里直接 require('fs')、把 token 放 IPC payload、不校验 sender

Electron 日志的三个核心决策点：存哪、怎么切、怎么查。

1. 存哪：主进程写 app.getPath('userData')/logs，渲染进程通过 IPC 转交，不要直接写文件系统
2. 怎么切：按大小滚动 + 按天滚动，绝对不要单文件无上限写入
3. 怎么查：开发环境直接 tail，生产环境用 electron-log 的文件路径 + 崩溃堆栈上报
4. 级别分级：error/warn/info 写文件，debug/trace 仅本地 console
5. 崩溃捕获：JS 异常走 uncaughtException，native 崩溃走 crashReporter，两条路不能混
6. 敏感信息：token / cookie / 密码进日志前必须 redact() 脱敏

React ref 和 forwardRef 不是一个层级的概念。

ref 是 React 故意不放入 props 的"逃生通道"，forwardRef 是把这个通道从 class 实例延伸到函数组件的桥梁。

• ref 是 React 特殊处理的 prop：class 组件默认挂到实例，函数组件默认拿不到
• forwardRef 把 ref 这个逃生通道"打通"到函数组件内部的 DOM 或组件实例
• 经典组合：forwardRef + useImperativeHandle，自定义暴露给父组件的方法集合
• displayName 给 DevTools 留个可读名字，避免看到一堆 "ForwardRef" / "Anonymous"
• React 19 起 ref 已经是普通 prop，forwardRef 即将退役——但理解它仍是排查老代码的基础

Chrome 用 4 个发布通道（Canary / Dev / Beta / Stable）同步推进，同一份代码按顺序流过所有通道后才进入 Stable。

1. Canary：每天构建，测试最少，可能导致崩溃。
2. Dev：每周 1-2 次构建，可能和 Canary 在同一个 MAJOR。
3. Beta：每周小更新 + 每 4 周大更新，比 Stable 早一个月以上拿到新功能。
4. Stable：每 2-3 周小更新 + 每 4 周大更新，分阶段从 1-5% 灰度到 100%。

核心反直觉："渠道 ≠ 版本"。MAJOR 号是里程碑（M101、M102、M103…），不是"我现在用的是第几代 Chrome"。同一时刻 Stable、Beta、Dev/Canary 经常对应 3 个连续的 MAJOR —— 但 Dev 和 Canary 可以共享同一个 MAJOR。

Vercel Labs 开源 scriptc，把 TypeScript 编译成不含 V8 的原生二进制。这条路 2016 年就有人走了。

• 不是新叙事：从 ts2c 到 Porffor 已经走了十年
• 分水岭在 三 档：静态编译 / 嵌引擎 / 拒绝编译并报错码
• 静态产物：170–200 KB，启动 2.4 ms，内存 1–4 MB
• 对照 Node SEA：60–100 MB，47 ms，67–116 MB
• Perry 早半年：押的是 Node 兼容性和 11 个平台
• 真正的争议：不是谁抄谁，是两边都由 AI 大规模生成
• 结论：CLI 和 Serverless 可以试，别现在卸载 Node

核心观点：CSS 级联按"属性"算胜负，不是按"类名"合并。

1. 裁决顺序：specificity → layer → 源码顺序，最后登场者赢
2. 冲突点：同一属性只能保留一个值，类名再多也是同一个声明位
3. 典型坑：layout.css 后加载的 .flex-col 会把 utils.css 的 .lg:flex-row 改回去
4. 回答"flex-col flex 能不能拆开"：不能，CSS 不按类名分摊属性
5. 推论：抢不同属性时互不干扰，按 reset/utilities/components 拆文件完全可行
6. 排查路径：DevTools → Computed → 看属性右边列出哪些规则在抢

微前端样式隔离的本质是"作用域隔离"——子应用样式限定在自己容器内，不污染全局。

1. 三种策略：默认不隔离、容器作用域隔离、Shadow DOM 强隔离
2. 工程首选：容器作用域，运行时或构建时给规则前置容器 ID
3. 核心做法：拦截样式表，自动加 #subapp .btn { ... }
4. 构建方案：PostCSS 插件打包阶段前置，零运行时开销
5. 根级陷阱：html/body/:root 不能前置，否则全局 reset 失效
6. Shadow DOM 代价：Ant Design / Arco 的 Portal 会被拦截，组件渲染错位
7. Portal 应对：选库时确认 Modal/Drawer 支持自定义挂载点
8. 结论：绝大多数项目走容器作用域，Shadow DOM 留给零污染少数场景

核心论点：pnpm link 验证的是本地源码，不是发布产物——两套验证面必须各走各的。

1. link 视角：指向本地源仓库，src/ 里有什么就能解析什么。
2. publish 视角：files 白名单外的目录全不进 tarball。
3. CI 视角：装的是 npm 上的发布包，看不到未列进 files 的源码。
4. 缺失验证：pnpm pack 解包 grep，文件齐全才算发布面 OK。
5. 踩坑信号：link 全绿、CI 找不到 module，99% 是 files 漏了。

CSS @layer 用声明式层级替代了特异性战争——无需 !important 也能精确控级。

1. 机制：先声明的层优先级最低，顺序决定一切
2. 核心：layer 优先于特异性，子选择器也能覆盖上层
3. 反转：!important 反转层级，重要样式反而走底层
4. 嵌套：子层用 . 访问，写成 @layer base.forms { }
5. 场景：框架 reset + 业务定制分层
6. 兼容：2023 起所有现代浏览器原生支持

Tailwind v3 的三条 @tailwind 指令对应 三个不同职责,不是同级概念。

1. @tailwind base:Preflight 重置,抹平浏览器默认
2. @tailwind components:复合组件类(.btn),中间层
3. @tailwind utilities:原子类,按需生成,最后输出
4. 级联顺序:base → components → utilities,后写的赢
5. v4 变化:三条合并成 @import "tailwindcss",components 删

原则:重置写 base,复合组件写 components,原子类写 utilities。