pr-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Secure PR Review

安全优先PR审查

输出语言: 使用中文输出所有审查报告内容。

Follow this workflow when reviewing code changes. Prioritize security > correctness > architecture > performance.

输出语言: 使用中文输出所有审查报告内容。

审查代码变更时遵循以下工作流。优先级为 安全 > 正确性 > 架构 > 性能。

Review scope (base branch)

审查范围（基准分支）

Review scope: treat
```
x
```
as the base (main) branch. Always review the PR as the diff between the current branch (HEAD) and
```
x
```
(i.e., changes introduced by this branch vs
```
x
```
).
Use PR semantics when generating the diff:
```
git fetch origin && git diff origin/x...HEAD
```
(triple-dot) to review only the changes introduced on this branch relative to
```
x
```
.

审查范围：将
```
x
```
视为基准（主）分支。始终以当前分支（HEAD）与
```
x
```
之间的差异来审查PR（即该分支相对于
```
x
```
引入的变更）。
生成差异时使用PR语义：
```
git fetch origin && git diff origin/x...HEAD
```
（三点语法），仅审查该分支相对于
```
x
```
引入的变更。

0) Scope the change & File Structure Analysis

0) 变更范围与文件结构分析

Identify what changed (files, modules, entrypoints, routes/screens).
Identify risk areas: auth flows, signing/keys, networking, analytics, storage, dependency updates.

识别变更内容（文件、模块、入口点、路由/页面）。
识别风险区域：身份验证流程、签名/密钥、网络、分析、存储、依赖项更新。

0.1 File Change Inventory (REQUIRED)

0.1 文件变更清单（必填）

Generate a structured overview of ALL changed files using this format:

markdown

undefined

使用以下格式生成所有变更文件的结构化概述：

markdown

undefined

PR File Structure Analysis

PR文件结构分析

Changed Files Summary

变更文件摘要

File	Change Type	Category	Risk Level	Description
`path/to/file.ts`	Added/Modified/Deleted	UI/Logic/API/Config/Test	Low/Medium/High	Brief description

文件	变更类型	分类	风险等级	描述
`path/to/file.ts`	添加/修改/删除	UI/逻辑/API/配置/测试	低/中/高	简要描述

Files by Category

按分类划分的文件

🔐 Security-Critical Files

🔐 安全关键文件

Files touching auth, crypto, keys, secrets

涉及身份验证、加密、密钥、机密的文件

🌐 API/Network Files

🌐 API/网络文件

Files with network requests, API calls

包含网络请求、API调用的文件

🧩 Business Logic Files

🧩 业务逻辑文件

Core logic, state management, services

核心逻辑、状态管理、服务

🎨 UI Component Files

🎨 UI组件文件

React components, styles, layouts

React组件、样式、布局

⚙️ Configuration Files

⚙️ 配置文件

package.json, configs, manifests

package.json、配置项、清单文件

🧪 Test Files

🧪 测试文件

Unit tests, integration tests

单元测试、集成测试

📦 Dependency Changes

📦 依赖项变更

package.json, lockfile changes

undefined

package.json、锁文件变更

undefined

0.2 Per-File Analysis (REQUIRED)

0.2 逐文件分析（必填）

For EACH changed file, provide:

markdown

undefined

对于每个变更文件，提供：

markdown

undefined

path/to/file.ts

path/to/file.ts

What This File Does:

Primary responsibility of this file

Changes Made:

Specific change 1
Specific change 2
...

Dependencies:

Imports from: [list key imports]
Exported to: [list files that import this]

Security Considerations:

Any security-relevant aspects

Cross-Platform Impact:

Extension
Mobile (iOS/Android)
Desktop
Web

undefined

变更类型: 添加 | 修改 | 删除 变更行数: +XX / -YY 分类: UI | 逻辑 | API | 配置 | 测试 风险等级: 低 | 中 | 高 | 严重

文件职责:

该文件的主要功能

变更内容:

具体变更1
具体变更2
...

依赖关系:

导入自: [列出关键导入项]
导出至: [列出导入该文件的文件]

安全考量:

任何与安全相关的方面

跨平台影响:

扩展
移动（iOS/Android）
桌面
网页

undefined

1) Secrets / PII / privacy (MUST)

1) 机密 / PII / 隐私（必须检查）

Do not allow logs/telemetry/error reports to include: mnemonics/seed phrases, private keys, signing payloads, API keys, tokens, cookies, session IDs, addresses tied to identity, or any PII.
Inspect all “exfil paths”:
```
console.*
```
, logging utilities, analytics SDKs, error reporting, network requests, and persistence:
- Web: localStorage / IndexedDB
- RN: AsyncStorage / secure storage
- Desktop: filesystem / keychain / sqlite
If any potential leak exists, explicitly document:
- source (what sensitive data),
- sink (where it goes),
- trigger (when it happens),
- impact (who/what is exposed),
- fix (concrete remediation).

禁止日志/遥测/错误报告包含助记词/种子短语、私钥、签名负载、API密钥、令牌、Cookie、会话ID、与身份绑定的地址或任何PII。
检查所有“泄露路径”：
```
console.*
```
、日志工具、分析SDK、错误报告、网络请求以及持久化存储：
- 网页：localStorage / IndexedDB
- React Native：AsyncStorage / 安全存储
- 桌面：文件系统 / 密钥链 / sqlite
如果存在潜在泄露风险，需明确记录：
- 来源（敏感数据类型），
- 去向（泄露至何处），
- 触发条件（何时发生），
- 影响（谁/什么信息被暴露），
- 修复方案（具体整改措施）。

2) AuthN / AuthZ (MUST)

2) 身份验证 / 授权（必须检查）

Verify authentication middleware/guards wrap every protected route and cannot be bypassed.
Verify authorization checks (roles/permissions) are correct and consistent.
Verify server/client trust boundaries: never trust client input for authorization decisions.

验证身份验证中间件/守卫是否包裹所有受保护路由，且无法被绕过。
验证授权检查（角色/权限）是否正确且一致。
验证服务端/客户端信任边界：绝不要信任客户端输入来做授权决策。

3) Dependency & supply-chain security (HIGHEST PRIORITY)

3) 依赖项与供应链安全（最高优先级）

package.json

/ lockfiles changed, you MUST do all of the following:

如果

package.json

/ 锁文件发生变更，必须完成以下所有检查：

3.1 Enumerate changes

3.1 枚举变更

List every added/updated/removed dependency with name + from→to version and the reason (if stated in PR).

列出每个添加/更新/移除的依赖项，包括名称 + 版本从→到以及PR中说明的变更原因（如有）。

3.2 Quick ecosystem risk check (before approve)

3.2 快速生态风险检查（批准前）

For each changed package:
- check for recent maintainer/ownership changes, suspicious release cadence, known advisories/CVEs, typosquatting risk.
- if your environment supports it, run commands like:
```
npm view <pkg> time maintainers repository dist.tarball
```
  .

对于每个变更的包：
- 检查近期维护者/所有权变更、可疑发布频率、已知漏洞/CVE、仿冒包风险。
- 如果环境支持，运行如下命令：
```
npm view <pkg> time maintainers repository dist.tarball
```
  。

3.3 Source inspection (node_modules) — REQUIRED when risk is non-trivial

3.3 源码检查（node_modules）——风险非微小时必填

Inspect the dependency’s

node_modules/<pkg>/package.json

and entrypoints (

main

module

exports

Grep for high-risk behavior (examples; expand as needed):
- outbound/network:
```
fetch(
```
  ,
```
axios
```
  ,
```
XMLHttpRequest
```
  ,
```
http
```
  ,
```
https
```
  ,
```
ws
```
  ,
```
request
```
  ,
```
net
```
  ,
```
dns
```
- dynamic execution:
```
eval
```
  ,
```
new Function
```
  , dynamic
```
require
```
  , remote script loading
- install hooks:
```
postinstall
```
  ,
```
preinstall
```
  ,
```
install
```
  , binary downloads
- privilege access: filesystem, clipboard, keychain/keystore, environment variables
Treat as HIGH RISK and block approval unless justified + isolated:
- any telemetry / remote config fetch / unexpected outbound requests
- any dynamic execution or install-time script behavior
- any access to sensitive storage or wallet-related data

检查依赖项的

node_modules/<pkg>/package.json

和入口点（

main

module

exports

）。

搜索高风险行为（示例；可按需扩展）：
- 出站/网络：
```
fetch(
```
  ,
```
axios
```
  ,
```
XMLHttpRequest
```
  ,
```
http
```
  ,
```
https
```
  ,
```
ws
```
  ,
```
request
```
  ,
```
net
```
  ,
```
dns
```
- 动态执行：
```
eval
```
  ,
```
new Function
```
  , 动态
```
require
```
  , 远程脚本加载
- 安装钩子：
```
postinstall
```
  ,
```
preinstall
```
  ,
```
install
```
  , 二进制文件下载
- 权限访问：文件系统、剪贴板、密钥链/密钥库、环境变量
以下情况视为高风险，除非有合理理由且已隔离，否则阻止批准：
- 任何遥测 / 远程配置获取 / 意外出站请求
- 任何动态执行或安装时脚本行为
- 任何对敏感存储或钱包相关数据的访问

3.4 React Native native-layer inspection (REQUIRED for RN libraries)

3.4 React Native原生层检查（RN库必填）

For React Native dependencies (or any package with native bindings:
```
.podspec
```
,
```
ios/
```
,
```
android/
```
,
```
react-native.config.js
```
, TurboModules/Fabric):
- Inspect iOS/Android native sources for security + performance.
- Confirm there are no unexpected outbound requests, no telemetry/upload without explicit product intent, and no access to wallet secrets/private keys/seed data.
- If necessary, drill into third-party native dependencies:
  - iOS: CocoaPods /
```
Pods/
```
    sources, vendored frameworks, build scripts
  - Android: Gradle/Maven artifacts, JNI/native libs, build-time tasks
- Treat any hidden network behavior, dynamic loading, install/build scripts, or obfuscated native code as HIGH RISK unless explicitly justified and isolated.

对于React Native依赖项（或任何包含原生绑定的包：
```
.podspec
```
,
```
ios/
```
,
```
android/
```
,
```
react-native.config.js
```
, TurboModules/Fabric）：
- 检查iOS/Android原生源码的安全性与性能。
- 确认无意外出站请求、无未经明确产品意图的遥测/上传、无对钱包机密/私钥/种子数据的访问。
- 如有必要，深入检查第三方原生依赖项：
  - iOS：CocoaPods /
```
Pods/
```
    源码、预编译框架、构建脚本
  - Android：Gradle/Maven制品、JNI/原生库、构建时任务
- 任何隐藏网络行为、动态加载、安装/构建脚本或混淆的原生代码，除非有明确理由且已隔离，否则视为高风险。

4) Mandatory callout when node_modules performs outbound requests

4) node_modules执行出站请求时必须标注

node_modules

code performs any outbound network/API request (directly or indirectly), call it out clearly in the review:

exact call site (file path + function)
destination (full URL/host)
payload fields (what data is sent)
headers/auth (tokens/cookies/identifiers)
trigger conditions (when/how it runs)
cross-platform impact (extension/mobile/desktop/web)

如果

node_modules

代码执行任何出站网络/API请求（直接或间接），需在审查中明确标注：

精确调用位置（文件路径 + 函数）
目标地址（完整URL/主机）
负载字段（发送的数据内容）
头部/身份验证（令牌/Cookie/标识符）
触发条件（何时/如何运行）
跨平台影响（扩展/移动/桌面/网页）

4.1 Extension manifest permissions changes (HIGHEST PRIORITY)

4.1 扩展清单权限变更（最高优先级）

If
```
manifest.json
```
(
```
permissions
```
,
```
host_permissions
```
,
```
optional_permissions
```
) changes:
- Call it out prominently as the top review item.
- Enumerate added/removed permissions and explain what new capabilities they enable.
- Assess least-privilege: confirm the permission is strictly necessary, scoped to minimal hosts, and does not broaden data access/exfil paths.
- Re-check data exposure surfaces introduced by the permission change (network, storage, messaging, content scripts, background/service worker).

如果
```
manifest.json
```
（
```
permissions
```
,
```
host_permissions
```
,
```
optional_permissions
```
）发生变更：
- 将其作为审查的首要项目突出标注。
- 枚举添加/移除的权限，并说明它们带来的新能力。
- 评估最小权限原则：确认该权限是严格必要的，作用域限定在最小主机范围，且未扩大数据访问/泄露路径。
- 重新检查权限变更引入的数据暴露面（网络、存储、消息传递、内容脚本、后台/服务工作者）。

5) Cross-platform architecture review (extension/mobile/desktop/web)

5) 跨平台架构审查（扩展/移动/桌面/网页）

Review the implementation as a senior multi-platform architect:

Is the approach the simplest correct solution with good maintainability/testability?
Identify platform pitfalls:
- Extension constraints (MV3/service worker lifetimes, permissions, CSP)
- RN constraints (WebView, native modules, backgrounding)
- Desktop (Electron security boundaries, IPC, nodeIntegration)
- Web (CORS, storage, XSS, bundle size, runtime differences)
If not optimal, propose a better alternative with tradeoffs.

以资深多平台架构师的视角审查实现：

该方案是否是最简单的正确解决方案，且具备良好的可维护性/可测试性？
识别平台陷阱：
- 扩展限制（MV3/服务工作者生命周期、权限、CSP）
- React Native限制（WebView、原生模块、后台运行）
- 桌面（Electron安全边界、IPC、nodeIntegration）
- 网页（CORS、存储、XSS、包大小、运行时差异）
如果方案并非最优，提出更好的替代方案并说明权衡。

6) React performance (hooks + re-render hotspots)

6) React性能（钩子 + 重渲染热点）

For new/modified components:

Check for unnecessary re-renders from unstable references:
- inline objects/functions passed to children
- incorrect hook dependency arrays
- state placed too high causing wide re-render fanout
Validate memoization strategy (
```
memo
```
,
```
useMemo
```
,
```
useCallback
```
) is correct (no stale closures / broken deps).
Watch for expensive work in render, list rendering issues, and missing cleanup for subscriptions/listeners.
Apply stricter scrutiny to new parent/child boundaries and call out any likely re-render hotspots.

对于新增/修改的组件：

检查是否存在因不稳定引用导致的不必要重渲染：
- 传递给子组件的内联对象/函数
- 错误的钩子依赖数组
- 状态放置层级过高导致大范围重渲染
验证记忆化策略（
```
memo
```
,
```
useMemo
```
,
```
useCallback
```
）是否正确（无过时闭包 / 依赖项错误）。
注意渲染中的昂贵操作、列表渲染问题以及订阅/监听器的清理缺失。
对新的父/子组件边界进行更严格的审查，并标注任何可能的重渲染热点。

7) Review output format (keep it actionable)

7) 审查输出格式（保持可执行性）

Focus on security/correctness/architecture/performance.
Avoid UI style / comment nitpicks unless they cause real bugs, security risk, or measurable perf regression.
Provide findings as:
- Blockers (must fix)
- High risk (strongly recommended)
- Suggestions (nice-to-have)
- Questions (needs clarification)

聚焦于安全/正确性/架构/性能。
除非导致实际bug、安全风险或可测量的性能退化，否则避免对UI样式 / 注释吹毛求疵。
以如下形式呈现审查结果：
- 阻塞项（必须修复）
- 高风险（强烈建议修复）
- 建议项（锦上添花）
- 疑问（需要澄清）

Additional resources

额外资源

Dependency audit: reference/dependency-audit.md
React performance: reference/react-performance.md
Cross-platform checks: reference/cross-platform.md
File analysis patterns: reference/file-analysis.md

依赖项审计：reference/dependency-audit.md
React性能：reference/react-performance.md
跨平台检查：reference/cross-platform.md
文件分析模式：reference/file-analysis.md

8) Architecture Visualization (REQUIRED)

8) 架构可视化（必填）

Generate ASCII diagrams to illustrate the PR's architectural impact. ASCII diagrams are terminal-friendly and don't require external tools.

生成ASCII图以展示PR的架构影响。ASCII图适用于终端环境，无需外部工具。

8.1 File Dependency Graph

8.1 文件依赖图

Show how changed files relate to each other:

text

┌─────────────────────┐     ┌─────────────────────┐
│   package.json      │────▶│     yarn.lock       │
└─────────────────────┘     └─────────────────────┘
          │
          ▼
┌─────────────────────┐     ┌─────────────────────┐
│   native patch      │────▶│   iOS/Android code  │
└─────────────────────┘     └─────────────────────┘

展示变更文件之间的关系：

text

┌─────────────────────┐     ┌─────────────────────┐
│   package.json      │────▶│     yarn.lock       │
└─────────────────────┘     └─────────────────────┘
          │
          ▼
┌─────────────────────┐     ┌─────────────────────┐
│   native patch      │────▶│   iOS/Android code  │
└─────────────────────┘     └─────────────────────┘

8.2 Data Flow Diagram

8.2 数据流图

For PRs involving data processing:

text

User Input ──▶ Validation ──▶ Business Logic ──▶ API Call
                                                    │
              UI Render ◀── State Update ◀──────────┘

对于涉及数据处理的PR：

text

User Input ──▶ Validation ──▶ Business Logic ──▶ API Call
                                                    │
              UI Render ◀── State Update ◀──────────┘

8.3 Component Hierarchy

8.3 组件层级

For UI changes, show component relationships:

text

ParentComponent
├── ChildA (props: data, onSubmit)
│   ├── GrandchildA1
│   └── GrandchildA2
└── ChildB (props: config)
    └── GrandchildB1

对于UI变更，展示组件关系：

text

ParentComponent
├── ChildA (props: data, onSubmit)
│   ├── GrandchildA1
│   └── GrandchildA2
└── ChildB (props: config)
    └── GrandchildB1

8.4 State Flow

8.4 状态流

For state-related changes:

text

[*] ──▶ Idle ──fetchData()──▶ Loading
                                 │
         ┌───────────────────────┼───────────────────────┐
         │                       │                       │
         ▼                       ▼                       │
      Success ──reset()──▶    Error ──retry()────────────┘
         │                       │
         └───────dismiss()───────┘
                    │
                    ▼
                  Idle

对于状态相关变更：

text

[*] ──▶ Idle ──fetchData()──▶ Loading
                                 │
         ┌───────────────────────┼───────────────────────┐
         │                       │                       │
         ▼                       ▼                       │
      Success ──reset()──▶    Error ──retry()────────────┘
         │                       │
         └───────dismiss()───────┘
                    │
                    ▼
                  Idle

8.5 Sequence Diagram

8.5 序列图

For async operations:

text

User          Component        Service           API
  │               │               │               │
  │──click()─────▶│               │               │
  │               │──callSvc()───▶│               │
  │               │               │──POST /api───▶│
  │               │               │◀──response────│
  │               │◀──result──────│               │
  │◀──update UI───│               │               │

对于异步操作：

text

User          Component        Service           API
  │               │               │               │
  │──click()─────▶│               │               │
  │               │──callSvc()───▶│               │
  │               │               │──POST /api───▶│
  │               │               │◀──response────│
  │               │◀──result──────│               │
  │◀──update UI───│               │               │

8.6 Cross-Platform Impact

8.6 跨平台影响

Show which platforms are affected:

text

Changed Code: packages/shared/src/sentry/basicOptions.ts

Platform Impact:
┌───────────┬───────────┬───────────┬───────────┐
│ Extension │  Mobile   │  Desktop  │    Web    │
├───────────┼───────────┼───────────┼───────────┤
│     ✓     │     ✓     │     ✓     │     ✓     │
└───────────┴───────────┴───────────┴───────────┘

Risk Level:  [HIGH]      [HIGH]      [MEDIUM]    [LOW]

展示受影响的平台：

text

Changed Code: packages/shared/src/sentry/basicOptions.ts

Platform Impact:
┌───────────┬───────────┬───────────┬───────────┐
│ Extension │  Mobile   │  Desktop  │    Web    │
├───────────┼───────────┼───────────┼───────────┤
│     ✓     │     ✓     │     ✓     │     ✓     │
└───────────┴───────────┴───────────┴───────────┘

Risk Level:  [HIGH]      [HIGH]      [MEDIUM]    [LOW]

Diagram Guidelines

图表示范

Always generate at least 2 diagrams for non-trivial PRs:
- File dependency graph (always)
- One domain-specific diagram (data flow / component hierarchy / state / sequence)
Use box-drawing characters:
- ```
┌ ┐ └ ┘ │ ─ ├ ┤ ┬ ┴ ┼
```
  for boxes and tables
- ```
▶ ◀ ▲ ▼
```
  for arrows
- ```
✓ ✗
```
  for status indicators
Highlight risk areas:
- Use
```
[HIGH]
```
```
[MEDIUM]
```
```
[LOW]
```
  labels
- Mark security-critical paths with
```
🔐
```
  or
```
⚠️
```
Keep diagrams focused:
- Max 10-15 nodes per diagram
- Split complex flows into multiple diagrams

对于非简单的PR，至少生成2个图：
- 文件依赖图（必选）
- 一个领域特定图（数据流 / 组件层级 / 状态 / 序列）
使用方框绘制字符：
- ```
┌ ┐ └ ┘ │ ─ ├ ┤ ┬ ┴ ┼
```
  用于方框和表格
- ```
▶ ◀ ▲ ▼
```
  用于箭头
- ```
✓ ✗
```
  用于状态指示器
高亮风险区域：
- 使用
```
[HIGH]
```
```
[MEDIUM]
```
```
[LOW]
```
  标签
- 用
```
🔐
```
  或
```
⚠️
```
  标记安全关键路径
保持图的聚焦：
- 每个图最多10-15个节点
- 将复杂流程拆分为多个图