参见 remix-v2-meta-sessions 获取权威实践模式。

快速参考

最高风险检测项 —— 应优先指出： 在 v2 项目中仍使用 v1 的 meta 对象结构（即 return { title, description }）。该写法可通过 TypeScript 类型检查，但运行时会被忽略，导致页面渲染时无标题且无任何 meta 标签。请对所有 export const meta 进行 grep 检查，并确认其返回值以 [ 开头，而非 {。

审查清单

• meta 返回 MetaDescriptor[]（数组以 [ 开头），而非 v1 对象结构
• OG / Twitter 标签使用 { property, content } 格式，而非 v1 简写格式 { "og:title": "..." }
• 不含 document.title = "..." 或 useEffect(() => { document.title = ... }) — meta 信息应通过 meta 导出声明设置
• root.tsx 在 内包含 和
• 子路由若需继承父级 meta 值，则使用 matches.flatMap((m) => m.meta ?? [])
• meta 对 data 做空值防护（loader 可能未执行 / 在 404 时返回 undefined）
• Cookie 配置中设置 httpOnly: true，且 secure: process.env.NODE_ENV === "production"
• secrets 从 process.env 读取（无硬编码字符串，.env.example 中无已提交的敏感值）
• secrets 是支持轮换的数组（新密钥前置，旧密钥保留），而非单一字符串值
• 所有 session.set/session.unset/session.flash 调用后，响应中均包含 "Set-Cookie": await commitSession(session)
• 鉴权检查位于 loader（或 action）中，通过 requireUserId(request) 实现 —— 不在组件内做重定向
• 登出为 action（POST），而非 loader（GET）
• 启用 CSRF 防护时，变更类 action 必须调用 csrf.validate(request)
• CSRF token 使用独立的 createCookie("csrf", ...) 创建，而非复用 session cookie
• 变更操作使用 / useFetcher，以便 AuthenticityTokenInput 自动注入 token（禁止手动 fetch POST）

有效模式（请勿标记为问题）

以下为正确用法，不应作为问题上报：

• sameSite: "lax" —— 可接受的默认值。并非所有应用都需要 "strict"；仅当威胁模型要求更强防护（例如：无其他 CSRF 防护措施）时才需标记。
• meta 返回 [] —— 若路由明确不需输出任何 meta 标签（例如继承 root 标签或依赖兄弟路由），此行为合法。
• links 返回 [] —— 若路由无专属样式表或预加载资源，此行为合法。
• session.flash(...) 后紧跟 commitSession(session) —— 此为标准的两行 flash 模式。分离写法是正确的，不应标记为“缺失 commit”。
• 鉴权检查位于 action（非 loader）中 —— 对仅支持 POST 的路由（如登出、删除）属正确做法。loader 用于保护 GET 请求，action 用于保护变更操作。
• charset 和 viewport 作为普通 JSX 元素直接写入 root.tsx 的 中 —— 推荐此方式，可避免 v2 的“不自动合并”行为引发重复标签警告。
• secrets: [process.env.X!, process.env.X_OLD!] —— 当上方存在 fail-fast 守卫（如 if (!process.env.X) throw）时，! 非空断言可接受。
• throw redirect(...) 出现在 loader/action 内 —— Remix 标准模式；抛出响应是预期行为。
• commitSession 在 loader 中调用（不仅限于 action） —— 当 loader 需读取 flash 消息并清除它时，此调用为必需。

上下文敏感规则

仅当满足特定上下文条件时，才标记以下问题：

硬性准入门禁（提交发现前必须完成）

请按顺序执行以下检查。除非当前批次所有门禁均已通过，否则不得起草面向用户的发现报告。

1. 位置证据 —— 通过标准： 每个问题需注明仓库路径，并附带具体行号范围或所查阅文件中的简短原文摘录。仅依据 diff 或记忆得出的结论不视为通过。对于 meta/links/session 类问题，引用文件必须是 .ts/.tsx 路由模块、root.tsx 或 *.server.ts —— 不得为通用配置文件。

2. 豁免核查 —— 通过标准： 对每个问题，需用一句话说明其为何不属于“有效模式（请勿标记）”所涵盖的情形。尤其需明确排除：sameSite: "lax"、空 meta/links 数组、以及标准的 flash + commitSession 两行模式。

3. Meta 结构核查 —— 通过标准： 在标记任何关于 meta 的问题前，必须阅读实际函数体并确认其返回值。TypeScript 类型可能掩盖真实结构（v1 对象可满足弱类型的 MetaFunction 别名）。核查要点：返回表达式以 [ 开头，且每个元素均为 descriptor 对象。若以 { 开头，则为 v1 结构 —— 标记为 CRITICAL；若为 []，则属合法（不标记）。

4. 流程合规 —— 通过标准： 已完成 review-verification-protocol 中规定的《提交前验证检查清单》。

何时查阅参考文档

• 审查任意 export const meta 或 export const links，或 root.tsx → 查阅 meta-v2-shape.md
• 审查 createCookieSessionStorage、createCookie，或任何配置 cookie 的 *.server.ts → 查阅 cookie-security.md
• 审查读写 session 的 loader/action，或任意 auth 辅助函数 → 查阅 auth-gates.md
• 审查表单、fetcher 或任意变更类路由 → 查阅 csrf.md

审查核心问题

1. 所有 meta 导出是否均返回数组？所有 OG/Twitter 标签是否均采用 { property, content } 格式？
2. root.tsx 是否在 内包含 和 ？
3. Cookie 是否设置了 httpOnly + secure: NODE_ENV === 'production'？secrets 是否来自环境变量且为数组（支持轮换）？
4. 每次 session 变更后，响应是否均包含 Set-Cookie: await commitSession(session) 头？
5. 鉴权是否在 loader/action 中通过抛出式辅助函数实现？是否从未在组件中实现？
6. 登出是否为 action（POST）？变更类 action 是否校验 CSRF（或已明确记录威胁模型）？

附加文档

• references/meta-v2-shape.md —— v2 项目中误用 v1 meta 对象结构（BREAKING）、OG 简写、document.title 反模式、root 模板搭建、父级合并逻辑
• references/cookie-security.md —— httpOnly/secure/sameSite 设置、硬编码密钥、密钥轮换规范
• references/auth-gates.md —— loader 层鉴权、登出必须为 action、commit 配对原则、flash 使用模式
• references/csrf.md —— remix-utils/csrf 集成方式、手动 fetch 绕过风险、专用 cookie 使用、共享密钥管理规范

提交发现前须知

请先完成全部硬性准入门禁（尤其是第 3 项 —— Meta 结构核查），再仅报告那些仍通过 review-verification-protocol 提交前验证检查的问题。