109 posts tagged with "全栈开发"

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。

Tailwind v4 重新设计 CSS 入口,几条新指令各司其职,不再像 v3 那样靠 @tailwind 堆叠。

1. @import "tailwindcss":替代 v3 的三条 @tailwind,整合 base + utilities
2. @theme:设计 token 入口,颜色字号间距都在这定义
3. @utility:自定义工具类,替代 v3 的 @layer 写法
4. @variant:自定义变体(hover / focus / ...),替代 v3 的 JS 配置
5. 级联顺序:v4 只剩 base → utilities 两层

核心:@theme 把设计 token 从 JS 搬到 CSS,样式与变量同源。

Electron 持久化没有"标准答案"，按数据类型选方案，比选库更重要。

1. 写对目录：一律写 app.getPath('userData')，打包后应用目录是只读的。
2. 配置 / 偏好：用 electron-store，一个 JSON 文件搞定，不用自己 fs。
3. 结构化大数据：上 better-sqlite3，同步 API，比 IndexedDB 省心。
4. 敏感信息：token / 密码走 safeStorage，落盘前用系统钥匙串加密。
5. 别踩的坑：renderer 里的 localStorage 会被用户清缓存清掉，不能当数据库。

Node-keytar 是 Node.js 上最成熟的 OS 钥匙串绑定库 —— 但它 已经 archived。

1. 本质：原生模块，分别封装 macOS Keychain、Windows Credential Vault、Linux libsecret
2. 核心 API：setPassword / getPassword / deletePassword / findCredentials 四件套
3. 适用场景：本地 CLI / 桌面工具保存用户 Token，不适合服务端容器
4. 现状：仓库 2022-12 已 archived，最后版本 7.9.0 停更 4 年
5. 替代方案：Electron 用 safeStorage，纯 Node 用 @napi-rs/keyring
6. 跨平台：macOS / Win 零配置；Linux 需 libsecret-1-dev + Keyring 服务在跑