2026-04-20 学习日志

今日主题

Vite 配置里的 envDir 用来重定向 .env 系列文件的查找目录，它影响的不只是配置文件读取，还影响 import.meta.env 和 Vite 运行时的环境注入。
单独调用 loadEnv(mode, 某目录) 只会让 vite.config.ts 自己读到该目录下的变量，并不会自动让整个 Vite 运行时也改用这个目录。
把 loadEnv(..., ui/env) 和 envDir: ui/env 同时配置，本质上是在统一配置层与运行层的环境变量来源，避免两边各读一套 .env。
在当前项目里，这种统一会直接影响代理目标、微前端域名改写和构建资源前缀等依赖 VITE_APP_* 变量的行为。

Device Flow 主要解决 CLI、终端工具这类无法可靠承接浏览器回调的授权场景，本质是把设备发起授权和浏览器中的人工确认拆开。
这类客户端属于 public client，代码运行在用户机器上，client_secret 无法真正保密；把 secret 硬编码进去只会制造伪安全。
Device Flow 的安全锚点不在客户端持有 secret，而在 GitHub 官方页面上的用户登录与手动授权，再辅以短期有效的 device_code/user_code、轮询限速等机制约束。

Vite 在前端代码里可靠暴露的是 import.meta.env，而不是 process.env；只有以 VITE_ 开头的变量会进入浏览器侧代码。
Supabase 的 publishable key 不是用户认证凭证，而是公开客户端访问项目 API 的接入凭证；真正的数据权限边界仍然依赖用户 JWT 和 RLS。
当 Supabase Auth 作为 SP 跳转到外部 IdP 登录时，RLS 使用的不是 IdP 原始 id_token/access_token，而是 Supabase 登录成功后自己签发的 session access token。
OAuth URL 里的 redirect_uri 是 GitHub 回给 Supabase callback 的协议层地址，redirect_to 是 Supabase 最后把浏览器送回前端的目标地址；流程真正的关联锚点是 state。
在纯前端 SPA 场景里，Supabase callback 域名不需要给业务站点种 cookie；浏览器被重定向回 redirectTo 后，supabase-js 会在站点域名下恢复 session 并默认持久化到 localStorage。

Supabase 的 anon key 不是用来保密的 secret，而是给公开客户端使用的项目访问凭证；它回答的是“哪个应用在访问项目”，不是“哪个用户在访问数据”。
真正的数据安全边界不在 anon key，而在 Auth 提供的用户 JWT 与数据库侧的 RLS policy；如果没有正确配置 RLS，anon key 几乎不提供实质性保护。
工程上更准确的理解是把 anon key 看成旧版的 publishable key：它的价值在于把前端低权限访问和后端 secret/service-role 访问分层，而不是单独承担安全职责。

当 Supabase Auth 作为 SP 接入外部 IdP 时，外部身份不会直接变成 RLS 使用的用户 ID；流程通常是先落成 auth.identities 中的外部身份，再关联到 auth.users 中的 Supabase 内部用户。
在这种 SP 模式下，后续数据库侧 auth.uid() 对应的是 Supabase 内部 user id，而不是外部 IdP 原始 token 里的 sub。
OAuth 流程里真正稳定的关联锚点是 state，而不是非标准的 redirect_to；redirect_to 更像 Supabase 记录的最终回跳目标。
纯前端 SPA 的 OAuth 登录不是靠 Supabase callback 域名给业务站点跨域种 cookie，而是靠浏览器回跳到业务站点后，由前端 SDK 读取 URL 中的授权结果并恢复 session。