2026-06-30

今日主题

• HMAC 与长度扩展攻击
• 密码学术语与算法标识体系
• 系统设计权衡
• JOSE/JWT 协议族分层
• AEAD 认证加密能力体系
• 加密认证组合与组合攻击
• Corepack 包管理器版本路由机制
• 云厂商权限认证体系
• 对话概览
• JOSE 密码学体系
• npm/npx 的 node_modules/.bin 注入机制
• Vite 环境变量与 import.meta 归属
• vite CLI 默认命令与 [root] 兜底

新增认知

HMAC 与长度扩展攻击

• 脉络：从 HMAC 结构到长度扩展攻击再到防御：这条推理链的起点是 HMAC 为什么不是简单 SHA256(key+msg)，
  终点是 HMAC 如何通过双层哈希封闭输入。中间的关键环节是理解 Merkle-Damgård 分块哈希的中间状态可被复用——
  攻击者拿到 H(prefix+msg) 就能算出 H(prefix+msg+padding+追加)，无需知道 prefix。
  HMAC 让外层哈希只看到内层输出的固定 32 字节，攻击者失去了追加的入口。

• HMAC 是双层嵌套哈希：HMAC(key, msg) = H((key⊕opad) + H((key⊕ipad) + msg))。
  内层先把 key⊕ipad 和消息一起哈希，外层再把 key⊕opad 和内层结果一起哈希。两层用了两个不同的 padding 常量（0x36 和 0x5c），
  从同一个 key 产生两个逻辑独立的有效密钥，避免内层和外层互相干扰。

• ipad/opad 是固定常量而非衍生密钥：ipad = 0x36 按哈希块大小重复（SHA-256 下 64 字节全是 0x36），
  opad = 0x5c 同理。它们不是从 key 派生的，只是通过与 key 做 XOR 把同一个 key 搅成两个不同的值，分别用于内层和外层哈希。
  这样设计保证只需要一个 key 就能实现密钥隔离。

• 长度扩展攻击利用了分块哈希的中间状态：SHA-256 等 Merkle-Damgård 结构不是一口吞掉消息，而是分 64 字节块逐块处理，
  每个块的输出是下一个块的输入。已知 H(secret+msg) 的值，这个值就是处理完 secret+msg+padding 后的中间状态，
  攻击者可以直接把它作为初始状态继续喂入追加内容，算出 H(secret+msg+padding+任意追加)，全程不需要知道 secret。
  API 签名如果只用 SHA256(key+msg) 就存在此风险。

• HMAC 防长度扩展攻击的关键是外层哈希输入被封印：外层哈希的输入是 (key⊕opad) + 内层哈希的 32 字节输出，这 32 字节是固定长度的，
  攻击者无法在其后追加任何内容。即使拿到最终 HMAC 值，也无法向前面的消息里追加——外层哈希的输入已经被内层输出封印了。

密码学术语与算法标识体系

• 脉络：从 MAC/签名区分到 JWA 标识再到 ES512 陷阱：对话从"感觉就是签名"出发，澄清了 MAC（对称密钥，
  无不可否认性）与数字签名（非对称密钥，有不可否认性）的严格边界——日常工程口语混用但在密码学课本中必须分开。由此引出 JWA 标准化标识体系，
  将 HMAC(RSA/ECDSA) 家族统一命名，再进一步发现 JWA 与 JDK JCA 底层是同一套密码学原语、只是命名不同，
  最后落到 ES512 的命名坑——数字 512 对应 SHA-512 哈希输出长度而非曲线位宽（曲线是 P-521）。

• MAC 无不可否认性，签名有：MAC 使用对称密钥，所有持有共享密钥的人都能生成和验证，因此 Alice 可以抵赖"这是 Bob 自己造的"。
  数字签名使用非对称密钥（私钥签名、公钥验签），只有私钥持有者能生成，天然具备不可否认性。工程上 MAC 更快更简单，适合通信双方互信场景；
  需要第三方验证或防抵赖时才升级到签名。

• JWA 的命名规律：前缀表算法族，数字表安全强度：H 前缀 = HMAC 系列（HS256/384/512），
  R 前缀 = RSA 签名（RS256/384/512），E 前缀 = ECDSA 签名（ES256/384/512）。数字对应 SHA 哈希输出长度，
  不直接对应密钥长度。这个命名体系来自 RFC 7518，是 JWT 生态里最通用的算法标识。

• JWA 与 JDK JCA 是同一套密码学，命名不同：HS256 → HmacSHA256，RS256 → SHA256withRSA，
  ES256 → SHA256withECDSA。
  JDK 的 javax.crypto.Mac 和 java.security.Signature 原生支持所有这些算法，
  JWT 库（auth0/java-jwt 等）底层就是调 JDK 这些 API，JWA 标识只是对外暴露的别名。

• ES512 命名陷阱：数字对应 SHA-512 而非 P-521：ES256 用 P-256 + SHA-256，
  ES384 用 P-384 + SHA-384，两条线数字恰好重合，形成"数字 = 曲线大小 = 哈希大小"的错觉。ES512 暴露了真相——
  曲线是 P-521（521 位），数字只对应哈希输出长度，不对应曲线位宽。

系统设计权衡

• 显式复杂度优于隐式复杂度：AWS STS 返回独立的 SessionToken 而非将其编码进 AK/SK，
  是因为显式复杂度（多一个字段）可控、可调试、调用方明确知道自己在做什么；隐式复杂度（把会话元数据塞进密钥内部编码）会让 AK/SK 变成黑盒，出问题时难以排查。
  工程上宁愿让接口多一个参数，也不要把多种语义压缩进同一个载体。自建系统如果规模允许服务端查状态，则只返回 AK/SK 的收敛方案可行且更干净。

JOSE/JWT 协议族分层

• 脉络：JOSE 是 JWS+JWE+JWK+JWA 四件套统称（RFC 7515-7518），JWT（7519）是载体层定义 Claims，
  JWS/JWE 是两种保护方式。分层关系：JWT 规定装什么、JWS 规定怎么签、JWE 规定怎么加密、JWA 是算法菜单、JWK 是密钥格式。
  日常说的 JWT 通常指 JWS 签名的三段式，但严格说 JWT 本身不定义签名，签名是 JWS 的职责。

• JWS 防篡改不防偷看：JWS 的 payload 是明文 base64，人人可读但改不了（签名不匹配即验不过）；JWE 防偷看，密文只有持密钥方能解，
  通常内部含 JWS 先签后加密。类比：JWS 是明信片加火漆印章（可见不可伪造），JWE 是上锁快递箱（不可见）。两者安全目标不同，
  机密性场景必须用 JWE 而非 JWS。

• JWE 五段语义：Header.EncKey.IV.CipherText.AuthTag。
  ①Header 声明 alg（密钥加密算法）和 enc（内容加密算法）；②EncKey 是 RSA 加密后的 CEK，收方用私钥解出会话密钥；
  ③IV 是 AES-GCM 的 nonce；④CipherText 是加密 payload 的输出；⑤AuthTag 是认证标签。
  第③④⑤段合起来就是一次完整 AES-GCM 加密输出，JWE 只是把它们拆开各自 base64url 编码。

AEAD 认证加密能力体系

• 脉络：从 JWE 第五段 AuthTag 追问「它从哪来」，答案是它不属于 AES 块密码而属于 GCM 工作模式，进而引出 AEAD 能力契约，
  再回溯到 JWE 为何强制要求 enc 带认证——历史上加密+认证拆开做出过 padding oracle 类事故，所以规范层面要求认证必须存在。

• AEAD 是能力契约非算法：AEAD=Authenticated Encryption with Associated Data，
  定义「加密+完整性+关联数据认证」三种能力，与 AES 正交。
  AES 可做成 AEAD（GCM/CCM/OCB）也可不做成 AEAD（CBC/CTR 裸用就没认证）；
  ChaCha20-Poly1305 是 AEAD 但底层根本不是 AES。判断一个算法是不是 AEAD 看它是否内置认证，不看底层用不用 AES。

• AuthTag 来自工作模式：AES 只是块密码（16字节明文块变16字节密文块），本身不产生 tag。
  tag 来自 GCM 工作模式内部的 GHASH 认证器，CTR 负责加密、GHASH 负责认证，两者共用同一密钥。反证：AES-CBC 就没有 tag。
  所以换工作模式决定有无 tag，JWE 第五段是否存在取决于 enc 是否选了 AEAD 或 CBC+HMAC 组合。

• AAD 是关联数据非 payload：AAD 走认证通道不走加密通道，不加密但解密时要校验，改 1 字节解密就失败。
  在 JWE 中 AAD=受保护 Header 的 base64url 字节，所以篡改 Header 即使密文没动 tag 也对不上。
  payload 和 AAD 是两条并行路：payload 被加密成密文（不可读），AAD 不被加密（可读）但被认证，两者都灌进认证器共同决定 tag。

• tag 是 MAC 不是签名：AEAD 的 AuthTag 是对称密钥生成的 MAC，加解密双方共享 CEK，收方理论上也能生成同样 tag，
  所以只能防篡改不能追责（无不可否认性）。JWE 场景够用（只需防篡改不需追责）；要追责（如电子合同）才需真正签名（JWS+非对称私钥，私钥唯一持有者才能生成）。
  混淆二者会导致安全模型错位。

• 原子绑定非加一层：手搓版 CBC+HMAC 是「加密后再加一层认证码」两步分立，人有机会写错顺序；
  AEAD 本质不是「加了认证」而是「加密和认证在算法内部原子绑定、无中间态」。判断 AEAD 不看「有没有认证码」看「是否原子绑定」，
  所以「加一层」是手搓版视角（恰是 AEAD 要取代的病根视角），「焊死」才贴合 AEAD 灵魂。

• 防篡改伪造非防碰撞：「碰撞」是哈希术语（找 x≠y 使 H(x)=H(y)），属哈希代数弱点离线穷举；
  AEAD 防的是篡改（tag 对不上即拒）和伪造（无密钥算不出正确 tag），与碰撞无关。术语混用会让哈希碰撞攻击和 AEAD 安全目标混淆，
  遇到真碰撞攻击（如 MD5 chosen-prefix）时概念打架。

加密认证组合与组合攻击

• 脉络：非 AEAD 算法（如 AES-CBC）要安全需手动「加密+认证」两步组合，这个组合的顺序和报错方式是人决定的，
  人会犯错→padding oracle 类事故；AEAD 把组合决策点焊死在算法里，从根上消除这类攻击。
  这是现代协议（TLS 1.3、QUIC、JWE 推荐）强制 AEAD 的真正原因，不是性能而是不依赖调用方纪律。

• padding oracle 病根：解密和认证分两步，两步间有可观测差异（不同报错/不同耗时）成为攻击者神谕。攻击者盲改密文 1 字节，
  通过服务器返回 padding 错还是 MAC 错逐字节还原明文（如 Cookie），全程不需读懂密文。乱码密文也要认证正因如此：
  攻击者穷举改 1 位让解密结果对自己有利即可。Lucky13 是 CBC+HMAC 的 timing 版，统一错误码后仍靠微秒级耗时差异区分。

• 手搓 vs 原生 AEAD：JWE 的 A128CBC-HS256 是手搓版（CEK 一分为二，K1 做 HMAC、K2 做 AES，
  自己拼 Encrypt-then-MAC），GCM 是原生版（一个 Seal 函数搞定）。手搓版安全全靠程序员自觉「先验 MAC 再解密+统一报错」，
  写反顺序或 MAC 算错对象都会漏；GCM 把这套焊死无踩坑空间。JWE 两种都允许但推荐 GCM，理由不是性能而是不依赖调用方纪律。

• 碰撞与oracle辨析：两者都「反复试」但机制不同。碰撞攻击是哈希领域离线穷举找两个不同输入同输出，不需外部反馈；
  padding oracle 是对称加密领域选择密文攻击（CCA），靠在线神谕（服务器报错信号）反馈逐字节逼近明文，更像 Mastermind 猜密码游戏。
  用「oracle/神谕」描述 padding oracle 精准，用「碰撞」是借喻但会误导，因 collision 已被哈希占用，混用让两套知识体系打架。

Corepack 包管理器版本路由机制

• Corepack 是 shim 代理而非静态安装：corepack enable 不下载真正的 pnpm，
  而是在 Node.js bin 目录创建拦截脚本（shim）。每次执行 pnpm 时，
  shim 读取项目 package.json 的 packageManager 字段解析版本，再从缓存按需下载对应版本执行。
  这套机制让不同项目自动使用各自声明的版本，无需开发者手动管理。

• 版本选择的三级优先级：
  项目 package.json 的 packageManager 字段 > corepack install -g 设置的全局默认（写进 lastKnownGood.json）> Corepack 内置的 lowest-known-good 版本。
  lastKnownGood.json 只在执行过 install -g 或 use 后才创建——
  纯靠项目 packageManager 字段的场景下该文件不存在是正常的。

• corepack use 与 install -g 的本质区别：use 是项目级操作，
  写入 package.json 的 packageManager 字段并立刻执行 install；install -g 只设定系统全局默认版本，不改项目文件，
  影响的是所有未声明 packageManager 的项目。--cache-only 只预热缓存不设默认。

云厂商权限认证体系

• Principal 与 Credential 的边界：Principal 是权限体系里的"谁"（身份实体，
  用 ARN 表示如 arn:aws:iam::123456:user/zhangsan），Credential 是证明身份的凭证。
  策略只能挂在 Principal 上不能挂凭证上——因为凭证会轮换过期而主体稳定。AK 和 SK 不是 Principal/Credential 的对应关系，
  而是同一个 Credential 的两个组成部分：AK 公开明文传输用于寻址（告诉服务端查哪个 SK），SK 秘密本地用于签名永不传输。
  容易误以为 AK=Principal、SK=Credential，实际两者合起来才是一个 Credential。

• IAM 是声明层不执行认证：IAM 本质是存规则的数据库（主体列表、策略文档、信任关系），不拦截请求、不验签名、不执行鉴权逻辑。
  真正执行认证和鉴权的是各服务（S3/EC2）自己的授权引擎，处理请求时去 IAM 查策略决定是否放行。容易误以为 IAM 是拦截所有请求的网关，
  实际它是户籍系统而非门卫。

• ARN 分层委派无限拓展：ARN（arn:aws:服务:地域:账号:资源）不是一张预列所有资源的表，而是分层命名规则，每段自治——
  命名空间/服务名/地域/账号/资源路径各管一段。新服务只需注册服务名其余段复用，权限系统和策略引擎自动兼容。本质是命名空间分层委派，
  和 URL（协议/域名/路径）、文件路径同构，上层定框架下层自治扩展，所以能无限拓展不是因为预想了所有资源而是什么都没预设。

• Role 信任策略与权限策略分层：Role 有两套独立策略——信任策略（Principal 控制"谁能扮演我走进来"，
  指定允许的 IAM User/服务/账号/SAML 联合身份）和权限策略（控制"扮演后能做什么"）。信任策略是 Role 独有的，
  User/Group 只有权限策略没有信任策略，因为它们不能被扮演。扮演流程是先匹配信任策略确认身份再授予权限策略。

• Role 只能通过扮演使用且单请求单Role：Role 没有长期凭证不能配 AK/SK，只能 Assume 系列扮演。
  变体有 AssumeRole（AK/SK 签名）/AssumeRoleWithSAML（企业 SSO）/AssumeRoleWithWebIdentity（含 EKS IRSA）/IAM Roles Anywhere（X.509 证书），
  本质都是用外部凭证换 Role 临时凭证。EC2/Lambda 看似不用扮演实则是基础设施在背后扮演。单次请求身份原子只能一个 Role，
  但进程可同时持有多个 Role 凭证按请求切换，角色链 A→B→C 串行但当前身份始终只有一个。

• 从 STS 为何还要 AK/SK 到全行业趋同（脉络）：起点是"STS 也需要 AK/SK"引发的困惑。深挖发现 STS 本质是带过期时间的 AK/SK，
  底层只有一套 HMAC 签名机制——AK 寻址、SK 签名，临时凭证要签名就必须有 AK/SK，所以 STS 发出的凭证结构必然是 AK+SK+Token。
  进一步追问"为什么多一个 Token"和"服务端能否靠 AK 查元数据"：服务端拿 SK 验签这步确实躲不掉，但 AK→SK 映射稳定可缓存、命中率极高；
  真正不可缓存的是"当前是否有效/属于谁"这种动态判断——过期时间在流逝、缓存没法做。Token 的作用正是把这一步从"查数据库"变成"本地验签+时间比对"，
  是 JWT 思路的复用。再深一层发现 AK 前缀编码凭证类型（AKIA=长期/ASIA=临时），服务端零开销识别并强制 ASIA 必须带 Token。
  最后落到结论：AWS 首创这套体系，HMAC 机制决定凭证结构，所有云厂商临时凭证都是 AK+SK+Token+Expiration、字段命名都照抄，
  是技术路径依赖而非设计选择。

• STS 本质是带过期时间的 AK/SK：不是替代 AK/SK 的另一套机制。临时凭证=临时 AK+临时 SK+Token，
  临时 AK/SK 和普通 AK/SK 长得一样、用法也一样（都走 HMAC 签名），Token 是唯一区别标志。

• AK/SK 与 STS 是两种认证手段非替代关系：AK/SK 永久有效泄露风险高，STS 自定义有效期几分钟到几小时自动失效。选用取决于场景，
  STS 把泄露窗口从"永久"压缩到"几小时"。

• STS 解决不了初始凭证来源：只在云厂商能担保身份的场景（EC2/Lambda 元数据服务、虚拟化层链路本地担保）才能做到代码零密钥。
  跨云、本地、移动端场景初始 AK/SK 必须存在某处（Secret 管理服务/Vault），STS 只缩短泄露窗口不消灭密钥。AK/SK 是不可完全消灭的——
  STS 的价值是把它藏得更深、用得更少、泄露后影响更小。

• Token 必须有的根因是性能而非安全：服务端拿 SK 验签这步躲不掉但可缓存（映射稳定命中率 99.99%）；
  真正不可缓存的是"当前是否有效/属于谁"的动态查询——过期时间在流逝缓存没法做，每次请求都查 STS 会导致瓶颈。Token 自包含过期时间+角色+签名，
  服务端用本地公钥验签读出元数据，零网络开销扛百万 QPS。安全性上 Token 没消灭窗口期内被滥用，只是把元数据查询从网络降到本地。

• AK 前缀编码凭证类型：
  AKIA=长期 IAM User 凭证/ASIA=STS 临时凭证/AROA=Role ID（非凭证不签名）/AIDA=UserID/AGPA=GroupID。
  服务端只看前四字母就知道凭证类型，ASIA 强制要求 X-Amz-Security-Token 头否则直接拒。AROA 是 Role 的机器唯一标识，
  ARN 可复用（删了再建同名 ARN 不变），Role ID 才是身份证号，审计追踪用 Role ID。

• Signature V4 派生锁作用域：签名密钥逐层派生（SK→日期密钥→地域密钥→服务密钥→最终签名密钥），把签名作用域锁死在日期×地域×服务格子，
  防跨服务/跨地域/跨时间重放，不依赖撤销机制凭证自带时效和范围。派生在 SDK 通用签名层执行而非 STS——签名是基础设施，调用任何 AWS 服务都需要，
  STS 只是被调用的服务不负责签名，纠正"派生是 STS 的事"的误解。

• 签名保证完整性不证明身份：HMAC 签名本身只能证明持有同一密钥和请求未篡改，不能证明你是谁。AWS 把认证拆两步：
  AK 明文提供身份声明（告诉服务端查哪个 SK），Signature 提供持有证明（用 SK 算出来对比）。本质是基于共享密钥的挑战应答，
  因 HTTP 无状态改成对请求内容签名顺便保了完整性。两者缺一不可——只有签名没 AK，服务端不知拿哪个 SK 验签。

• EC2 云内认证靠虚拟化层：EC2 访问元数据服务（169.254.169.254）不需要 AK/SK，
  靠链路本地地址只有本机能访问加虚拟化层 hypervisor 担保请求来自哪个实例。这是云内服务身份认证靠基础设施层（网络隔离）而非密码学。
  之后调 AWS API 才靠 STS 临时凭证签名——两层认证：元数据查身份靠虚拟化层，API 调用靠 STS 凭证签名。这也是云内场景能做到代码零密钥的根因。

对话概览

• Git fetch 与 pull 的区别确认：本次对话确认了 git fetch（仅同步远程状态到本地远程跟踪分支，
  不影响工作区）和 git pull（fetch + merge，会将远程变更合并到当前工作区）的区别。用户已有正确理解，对话仅为确认性讲解。

JOSE 密码学体系

• 脉络：从体系分层到密钥协商的安全性边界：整个对话沿 JOSE 规范家族从外到内逐层深入——先厘清 JWA/JWK→JWS/JWE→JWT 的分层关系，
  纠正"JWT 必须非对称"的误解，再拆解 JWE 两种密钥管理模式（Key Encryption vs ECDH-ES），
  最终落到 ECDH-ES 的椭圆曲线数学原理和安全性边界（前向安全有、后向安全无）。核心线索是"密钥怎么安全到达对方"这个问题在不同层次上的不同解法。

• JOSE 是分层体系，JWT 只是最上层：JWA（算法注册表）和 JWK（密钥 JSON 表示）是底层基础，
  支撑 JWS（签名容器）和 JWE（加密容器），JWT 构建在 JWS/JWE 之上的声明（claims）语义层。业务数据保护应直接用 JWS/JWE，
  不应硬套 JWT 的 claims 语义——JWT 解决的是"关于某主体的断言"，不是通用数据容器。

• JWT/JWS/JWE 不强制非对称密钥：HS256 等对称算法完全合法，一个 secret 既签名又验证。对称适合单服务自签发自验证场景，简单高效；
  非对称（RS256/ES256/EdDSA）适合多方验证或需要对外暴露公钥的场景（如 OIDC 的 JWKS endpoint）。

• JWE 两层加密：内容层固定，密钥管理层可变：内容加密永远是 CEK（随机内容密钥）+ AES-GCM，变的是 CEK 如何安全到达接收方。三种模式：
  dir（直接用共享对称密钥加密内容，
  最简单）、Key Encryption（用接收方公钥加密 CEK 后附在 JWE 里传输）、ECDH-ES（双方各自通过 DH 算出相同 CEK，不传输）。

• ECDH-ES 的数学本质是椭圆曲线标量乘法的交换律：
  eph_priv × recv_pub = eph_priv × recv_priv × G = recv_priv × eph_priv × G = recv_priv × eph_pub。
  不是两个密钥对之间有数学关系，临时密钥对和静态密钥对各自独立随机生成，只是"交叉乘"这个运算本身满足交换律。

• 前向安全保护过去，后向安全保护未来：前向安全（Forward Secrecy）= 今天密钥泄露不解密历史消息；
  后向安全（Backward Secrecy）= 泄露后换新密钥，未来消息仍安全。ECDH-ES 有前向安全（临时私钥用完即弃，泄露长期私钥也算不出历史 Z），
  无后向安全（静态私钥不变，泄露后攻击者能参与未来所有协商算出 Z）。两者都想要需要每次通信都重新协商密钥（如 Signal 双棘轮）。

npm/npx 的 node_modules/.bin 注入机制

• 脉络：从"为什么 IDEA 终端能执行 devDeps 的 bin"出发，逐步排除 shell PATH、IDEA 插件等猜测，
  最终定位到 npx 和 npm run 的 PATH 注入机制——
  两者都通过临时追加 node_modules/.bin 到子进程 PATH 来让本地依赖的 bin 可执行，
  但 node -e 和 echo PATH 不受影响，代表 shell 的真实 PATH。

• npx 递归注入 PATH：npx 执行时会递归向上查找 node_modules/.bin（从当前目录到根目录）并追加到子进程 PATH，
  所以 npx vite 能找到本地安装的 vite。用 npx node -e 检查 PATH 会看到 npx 魔改过的版本，
  不能代表 shell 真实 PATH。

• npm run 的 PATH 注入：
  npm/pnpm/yarn run 执行 scripts 时也会临时把 node_modules/.bin 追加到 PATH，
  所以 package.json 的 "dev": "vite" 能直接找到 vite。与 npx 区别：npx 执行任意命令，
  npm run 只执行 scripts 里定义的命令。

Vite 环境变量与 import.meta 归属

• --mode 只管 MODE 与 env 文件，不改 NODE_ENV：
  vite build --mode staging 让 import.meta.env.MODE 变为 staging 并加载 .env.staging，
  但 NODE_ENV 仍默认 production（除非显式设）；DEV/PROD 由 NODE_ENV 决定、与 mode 无关。前置：Vite 4+。
  ui/ 的 build:d1/build:pre/build:prod 即靠不同 --mode 加载不同 .env.*。

• import.meta.env 归 Vite，import.meta 归 ES 标准：import.meta 是 ES2020 语言标准，所有现代运行时支持，
  标准只规定 .url 一个属性；import.meta.env 是 Vite 借此挂载点扩展的属性，原生浏览器/Node 里为 undefined。

• Vite 选 import.meta 挂 env 的两层理由：语义上 import.meta 即"当前模块元信息"，环境变量天然属模块上下文；工程上它是编译期可静态分析的表达式，build 时把 import.meta.env.DEV 静态替换为字面量以启用 tree-shaking。
  项目自定义的 DEV_MODE（vite.config.ts define 纯文本替换、不走 import.meta）是另一条实现路径，两者语义重叠但不等价。

vite CLI 默认命令与 [root] 兜底

• 默认命令兜底机制：vite 用 cac 注册了一个无名默认命令 .command('[root]', 'start dev server')，
  alias 为 serve/dev。任何不匹配具名子命令(build/preview/optimize)的位置参数都会兜底走默认命令，
  被当成 dev server 的 root 路径吞掉，而非报未知命令。所以 vite adb 不会报错——adb 被解析为 root，
  dev server 照常启动。前置条件:第一个位置参数不是 build/preview/optimize 等具名子命令。

• dev server 启动与入口文件解耦：
  vite dev server 的 HTTP 监听就绪(打印 ready)不依赖 root 目录存在、也不依赖有 index.html。
  root 指向不存在的目录时，server 仍能 ready，只是访问任何路径都返回 404，
  并可能伴随 'Could not auto-determine entry point' 警告。本质:监听是网络层行为，入口解析是请求时才发生的应用层行为，
  两者解耦。这也是为什么 vite adb 看起来'能跑'实则是个空壳。

• root 位置参数决定配置加载范围：vite 从 root 目录(及其上级)查找 vite.config.*。当 adb 被当成 root，
  vite 在 ui/adb/ 下找不到配置文件，于是 ui/vite.config.ts 完全不加载——
  debug 日志可见 'no config file found' + configFile: undefined。
  结果是 server.port/host/open 等自定义配置全部失效，端口回退到 vite 默认 5173。
  判断 vite 是否加载了项目配置:看实际端口是不是配置里写的值、host 是否绑定到配置域名、有没有触发 open。

• [root] 是可选位置参数声明：cac 命令定义语法中，方括号 [ ] 表示可选位置参数，尖括号 < > 表示必填。
  .command('[root]') 里命令名为空代表默认命令，[root] 表示一个名为 root 的可选参数槽位——给了就用作 root，
  不给(undefined)则 vite 内部回退到 process.cwd()。root 这个词只是参数名，供 action 回调按名取值，
  方括号本身才表达'可选'语义。对比 vite 其他命令:build [root] 是具名命令+可选 root，optimize 是具名命令无位置参数。