它的业务目标很简单：输入小说章节或短剧文本，系统拆解角色、空间、道具、场次和分镜，再生成资产图、3D 运镜预览和图生视频任务。功能层面可以概括成“文本 -> 世界资产 -> 分镜 -> 3D 运镜 -> 视频片段”。

系统实现重点包括：Next.js 全栈架构、Route Handlers 后端接口、Prisma + MySQL 数据模型、AgentRun / AgentStep 状态机、AI Provider 抽象、Three.js 预览、任务恢复，以及 Docker + GitLab CI/CD 部署。

整体技术架构

项目是一个 Next.js 全栈应用，前端页面、服务端 API、Agent 编排、数据库访问、OAuth 登录和部署配置都在同一个工程里。

核心技术栈：

• Next.js 16 App Router
• React 19
• TypeScript
• Tailwind CSS
• Three.js
• Prisma 7
• MySQL
• Google OAuth
• Qwen 文本模型
• Doubao Seedream 图片模型
• Doubao Seedance 图生视频任务
• Docker
• GitLab CI/CD
• Nginx

整体链路如下：

1
2
3
4
5
6
7

React 页面
  -> Next.js Route Handlers
  -> AgentRun / AgentStep 状态机
  -> AI Provider 层
  -> Prisma / MySQL
  -> 本地资产存储与缩略图
  -> Three.js 预览 / 图片与视频任务结果

系统按职责拆成几层：

• UI 层：负责工作台交互、任务进度展示、资产编辑和 3D 预览。
• API 层：使用 Next Route Handlers 承接登录、剧本解析、生成任务、Agent 执行和资产管理。
• Agent 层：负责任务计划、步骤执行、状态流转、人工确认和失败重试。
• Provider 层：屏蔽不同 AI 模型的请求参数、返回结构和错误处理。
• Data 层：用 Prisma + MySQL 持久化用户、任务、资产、分镜和 Agent 状态。
• Deploy 层：使用 Docker 镜像、migrator 镜像、GitLab CI/CD 和 Nginx 发布到生产环境。

前端：App Router 下的工作台式页面组织

这个项目不是营销页，而是偏工具型的工作台，所以前端信息架构按“主流程 + 可插入工具”组织。

主要页面包括：

• /：产品入口和主流程说明。
• /agent：Agent 导演台，创建和执行 AgentRun。
• /scripts：剧本解析工作台。
• /scripts/[id]/world：世界资产编辑页面。
• /storyboard-3d：3D 运镜预览器。
• /generate：图片和视频生成工作台。
• /login：Google OAuth 登录入口。
• /about：项目架构介绍。

前端比较关键的不是 UI 本身，而是状态展示方式。Agent 任务不是一次请求立即返回结果，而是分步骤执行，所以页面需要展示：

• 当前 AgentRun 状态。
• 每个 AgentStep 的状态。
• 正在执行的步骤。
• 等待用户确认的步骤。
• 失败步骤和错误信息。
• 可重试入口。
• 已生成的中间产物。

这类页面不能只靠一个简单 loading。它更像任务控制台，需要把后端状态机完整映射到前端。

后端：Route Handlers 作为 BFF 和任务入口

项目后端没有单独起 Express 或 Nest 服务，而是使用 Next.js Route Handlers。

这种选择的好处是：

• 页面和 API 可以共享 TypeScript 类型。
• 服务端代码可以直接访问 Prisma、Cookie、环境变量和 Provider。
• 部署时可以走 Next standalone 镜像。
• 对个人项目来说工程复杂度更低。

典型 API 包括：

• POST /api/agent/runs：创建 AgentRun 和 AgentStep。
• POST /api/agent/runs/[id]/start：启动 Agent 执行。
• POST /api/agent/steps/[id]/confirm：确认等待中的步骤。
• POST /api/agent/steps/[id]/retry：重试失败步骤。
• POST /api/scripts/analyze：解析剧本。
• POST /api/scripts/novel/condense：精简小说。
• POST /api/scripts/novel/to-script：小说转短剧剧本。
• POST /api/world/assets/[id]/generate-image：生成世界资产图。
• POST /api/world/storyboards/[id]/generate-image：生成分镜图。
• POST /api/world/storyboards/[id]/sync-video：同步视频结果。
• GET /api/auth/me：读取当前登录用户。

Route Handler 里会做几件事：

1. 读取并校验请求参数。
2. 通过 Cookie Session 获取当前用户。
3. 调用 Prisma 查询或写入数据库。
4. 调用 Agent executor 或 AI Provider。
5. 返回结构化 JSON 给前端。

API Key、模型调用、文件转存都只在服务端发生，前端不直接接触模型密钥。

数据建模：把 AI 过程拆成可恢复的业务对象

AIGC 项目如果只保存最终图片或视频，很快会遇到两个问题：

1. 中间过程不可追踪。
2. 失败后只能重来。

所以这个项目的数据库设计重点不是“保存结果”，而是“保存生成过程”。

核心模型包括：

这里最关键的是 AgentRun 和 AgentStep。

AgentRun 记录一次完整目标，比如“把这段小说转成视频预视觉”。AgentStep 则记录每一个可执行节点，比如“精简小说”“生成资产图”“等待用户确认”“生成分镜图”。

这种设计让系统具备几个能力：

• 可以看到任务执行进度。
• 可以保存每一步输入和输出。
• 可以从失败步骤重试。
• 可以保留已成功的中间产物。
• 可以让用户在关键节点确认后再继续。
• 可以把长任务拆成多个短事务。

Agent 设计：模板计划 + 状态机，而不是黑盒自由 Agent

这个项目没有一开始引入复杂 Agent 框架，而是先实现了一个轻量可控的工作流 Agent。

原因很直接：短剧生成链路强依赖业务数据、资产关系、用户确认和成本控制。如果完全交给模型自由规划，很容易出现不可控的工具调用和难以恢复的状态。

所以当前 Agent 采用：

1
2
3
4
5
6

AgentRunType
  -> buildInitialAgentPlan
  -> AgentStep[]
  -> executor 按顺序执行
  -> 写入 outputJson / errorMessage
  -> 更新 run.status 和 currentStepId

当前支持的 AgentRunType：

• novel_to_video_preview
• script_to_video_preview
• asset_generation
• storyboard_generation
• video_generation

当前支持的 AgentStepType：

• condense_novel
• convert_novel_to_script
• analyze_script
• confirm_world_assets
• generate_world_asset_images
• generate_scene_storyboards
• build_scene_director_plan
• generate_video_clips
• generate_final_report

AgentStep 状态：

1
2
3
4
5
6

pending
running
waiting_user_confirm
succeeded
failed
skipped

AgentRun 状态：

1
2
3
4
5
6
7

draft
pending
running
waiting_user_confirm
succeeded
failed
cancelled

最重要的设计点是 waiting_user_confirm。当系统解析出角色、空间和道具后，不会立刻消耗模型资源继续生成图片，而是暂停等待用户确认。

这一步让 Agent 从“全自动黑盒”变成“可控半自动工作流”。对生产工具来说，这比单纯追求自动化更实用。

Executor：长任务拆步执行与失败恢复

Agent executor 的职责是找到当前待执行步骤，执行对应工具，然后把结果写回数据库。

执行过程可以抽象成：

1
2
3
4
5
6
7
8
9

读取 AgentRun + AgentStep
  -> 构建 ExecutionContext
  -> 找到下一个 pending step
  -> step.status = running
  -> 调用对应 tool
  -> 成功：写 outputJson，step.status = succeeded
  -> 需要确认：step.status = waiting_user_confirm，run.status = waiting_user_confirm
  -> 失败：写 errorMessage，step.status = failed，run.status = failed
  -> 更新 currentStepId

ExecutionContext 会把前面步骤的输出合并起来，让后续步骤可以复用：

• 精简后的小说。
• 转换后的剧本。
• scriptAnalysisId。
• 已生成资产数量。
• 分镜数量。
• 视频任务数量。

失败恢复也基于这个模型。重试失败步骤时，只需要把当前步骤及后续未完成步骤重置为 pending，已成功步骤保持不变。这样用户不会因为某一步模型失败而丢掉所有产物。

AI Provider 抽象：把模型差异隔离到服务端

项目目前主要接了三类模型能力：

• Qwen：文本理解、小说精简、小说转剧本、剧本结构化解析、分镜生成。
• Doubao Seedream：文生图、图生图、角色/空间/道具主图、分镜主视觉图。
• Doubao Seedance：图生视频任务。

Provider 层解决的问题是：业务代码不应该关心不同模型的具体请求格式、字段名、错误结构和 URL 处理。

因此页面和 Agent executor 只关心标准化后的能力：

1
2
3
4
5

analyzeScript()
generateImage()
editImage()
createVideoTask()
syncVideoTask()

模型层内部再处理：

• 模型名称归一化。
• Prompt 安全规则。
• 请求参数拼装。
• 响应结构解析。
• 错误信息转换。
• 图片或视频 URL 本地化。
• 额度耗尽、配置缺失等异常提示。

这样后续如果要增加新模型，只需要扩展 Provider，不需要改 Agent 主流程。

Prompt 与结构化输出

这个项目里 Prompt 不是随手拼字符串，而是围绕“结构化结果可入库”设计。

文本模型输出需要服务于数据库结构：

• 剧本解析要产出角色、空间、道具和场次。
• 世界资产要有名称、类型、描述、关键词、提示词和负面提示词。
• 场次要有地点、情绪、关键动作、空间关系和视觉重点。
• 分镜要有镜号、原文、图片提示词、视频提示词、镜头运动和对白。

也就是说，Prompt 的目标不是“生成一段好看的文字”，而是生成后端可以继续处理的数据。

这种设计有两个好处：

• 前端能稳定渲染编辑表单。
• 后续步骤能稳定引用前一步结果。

Three.js：把分镜信息转成可视化运镜草案

Three.js 在这个项目里不是做炫技 3D 场景，而是承担“运镜预览”的角色。

它消费的数据来自后端：

• 场次地点。
• 角色列表。
• 道具列表。
• 空间关系。
• 分镜信息。
• 镜头运动。
• 视觉焦点。

前端再把这些信息转成基础站位、摄像机位置、注视点和路径预览。这样用户可以更直观看到“这场戏大概怎么拍”。

这个模块的价值在于：后续视频模型不只拿到一句自然语言描述，还可以拿到结构化的镜头关系。即使当前 3D 预览还不是完整制作工具，它也为后续更精细的视频生成预留了数据接口。

资产存储：外部 URL 本地化与缩略图

AI 图片和视频模型返回的 URL 往往有有效期，不能直接当长期资产使用。

所以项目做了本地化存储：

• 生成图片后保存原图。
• 生成 WebP 缩略图。
• 列表和卡片优先读取 thumbnailUrl。
• 详情页和下载再读取原图。
• 下载通过服务端代理，减少浏览器 CORS 问题。
• /uploads/ 在生产环境中用 volume 挂载。
• Nginx 可以直接服务静态资源，避免所有图片流量都打到 Next 容器。

这部分虽然不如 Agent 听起来亮眼，但对 AIGC 项目很关键。否则图片链接过期后，历史记录就会失效。

登录、额度与安全

登录使用 Google OAuth。用户登录后自动创建账户，并通过 Cookie Session 识别当前用户。

额度系统目前主要用于管理 AI 生成成本和任务使用边界：

• 图片生成、图片编辑、资产主图、分镜图和视频任务都有独立成本记录。
• 生成失败、配置错误或额度耗尽时不会记录为成功消耗。
• 当前项目还没有开放付费购买额度，后续会接入订单和支付模块。

安全上主要做了几个约束：

• API Key 只放在服务端环境变量。
• 前端不直接请求模型 API。
• 所有模型调用都通过 Route Handlers。
• 生产环境变量通过 GitLab CI/CD File 类型变量注入。
• OAuth 回调地址通过环境变量区分本地和生产环境。

Docker 与 GitLab CI/CD

项目已经部署到生产环境，线上地址是：https://devflow.aiyly.com/。

部署方案不是直接在服务器上拉代码构建，而是走 Docker 镜像：

1
2
3
4
5
6
7
8

GitLab CI
  -> docker build 应用镜像
  -> docker build migrator 镜像
  -> push 到 GitLab Registry
  -> SSH 到服务器
  -> docker compose pull
  -> migrator 执行 prisma db push
  -> docker compose up -d

Dockerfile 分为几个阶段：

• deps：安装依赖。
• migrator：只保留 Prisma 迁移需要的内容。
• builder：生成 Next standalone 产物。
• runner：运行生产服务。

Docker Compose 里有两个服务：

• aigc-video-studio：主应用。
• aigc-video-studio-migrate：数据库迁移服务。

这种拆法的好处是生产镜像不会携带完整开发环境，迁移也不会和应用启动强耦合。

这个项目里比较有价值的技术点

从技术角度看，这个项目最值得总结的是下面几件事：

1. Agent 不一定要一开始就上复杂框架

对于业务步骤明确、状态要求强、需要用户确认的系统，模板计划 + 状态机 + 工具函数，比自由 Agent 更稳定。

后续如果分支、循环、并行工具调用变复杂，再引入 LangGraph.js 这类状态图框架会更自然。

2. AI 应用要优先设计“中间态”

很多 AI Demo 只保存最终结果，但真实工具更需要中间态：

• 用户输入。
• 模型增强后的 Prompt。
• 结构化解析结果。
• 候选图。
• 资产版本。
• 分镜。
• 视频任务。
• 错误信息。
• 每一步执行状态。

这些中间态决定了系统是否能恢复、复用和迭代。

3. 生成任务要从第一天考虑失败

AIGC 调用不稳定是常态。网络、额度、内容安全、模型输出格式、图片地址有效期，都可能导致失败。

所以任务系统应该默认支持：

• 失败记录。
• 单步重试。
• 状态回滚。
• 已成功结果保留。
• 用户确认后继续执行。

4. Provider 抽象能降低后续换模型成本

模型变化很快，业务代码如果直接绑定某个厂商的字段，很快会变得难维护。

把模型能力封装成 Provider 后，Agent 和页面只依赖内部统一接口，后续替换模型会轻很多。

后续技术规划

后续优先补齐这些技术能力：

• 额度购买、订单支付和套餐系统。
• 更完整的视频任务队列。
• 视频状态轮询和回调同步。
• 角色语音包、配音和字幕。
• 多视频片段排序和成片导出。
• 更强的角色一致性策略。
• 更细粒度的镜头参数控制。
• 引入对象存储，替换本地 uploads。
• 当 Agent 流程复杂后，引入 LangGraph.js 或自研更完整的 state graph。

最终目标不是做一个“点按钮生成视频”的页面，而是做一个可持续扩展的 AI 短剧制作系统：前端能承载复杂工作流，后端能管理长任务和资产，Agent 能稳定编排多模型，数据层能保存完整创作过程。

这篇记录一些 TypeScript 里比较实用的高级用法。

类型收窄：让联合类型变得可控

联合类型很常见，比如接口返回状态、组件 props、任务状态等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

type Task =
  | { status: "pending"; id: string }
  | { status: "running"; id: string; startedAt: string }
  | { status: "failed"; id: string; errorMessage: string }
  | { status: "succeeded"; id: string; resultUrl: string };

function renderTask(task: Task) {
  if (task.status === "failed") {
    return task.errorMessage;
  }

  if (task.status === "succeeded") {
    return task.resultUrl;
  }

  return task.id;
}

这里的 status 是判别字段，TypeScript 会根据 if 条件自动收窄类型。这样比写一堆可选字段更安全。

不推荐这样写：

1
2
3
4
5
6

type BadTask = {
  status: "pending" | "running" | "failed" | "succeeded";
  id: string;
  errorMessage?: string;
  resultUrl?: string;
};

因为 status === "failed" 时，errorMessage 在类型上仍然可能是 undefined。判别联合类型能把“某个状态下一定有哪些字段”表达得更准确。

never：保证分支穷尽

当联合类型变多时，很容易漏处理某个状态。可以用 never 做穷尽检查。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

function assertNever(value: never): never {
  throw new Error(`Unexpected value: ${value}`);
}

function getTaskText(task: Task) {
  switch (task.status) {
    case "pending":
      return "等待中";
    case "running":
      return "运行中";
    case "failed":
      return task.errorMessage;
    case "succeeded":
      return task.resultUrl;
    default:
      return assertNever(task);
  }
}

如果以后给 Task 新增一个 cancelled 状态，但忘记在 switch 里处理，assertNever(task) 会直接报类型错误。

这在状态机、订单状态、权限状态、Agent 步骤状态里都很有用。

泛型约束：既灵活又保留字段限制

泛型不是为了炫技，而是为了让函数在复用时保留输入和输出之间的关系。

比如写一个根据 id 找元素的函数：

1
2
3
4
5
6
7
8
9
10
11

function findById<T extends { id: string }>(list: T[], id: string): T | undefined {
  return list.find((item) => item.id === id);
}

const users = [
  { id: "u1", name: "Ada" },
  { id: "u2", name: "Grace" },
];

const user = findById(users, "u1");
// user 的类型是 { id: string; name: string } | undefined

T extends { id: string } 表示：调用者传什么对象都可以，但必须有 id 字段。返回值仍然保留原来的完整类型。

keyof：把对象 key 变成类型

keyof 可以拿到对象类型的所有 key。

1
2
3
4
5
6
7
8

type User = {
  id: string;
  name: string;
  email: string;
};

type UserKey = keyof User;
// "id" | "name" | "email"

一个常见场景是封装安全的取值函数：

1
2
3
4
5
6
7
8
9
10
11

function getValue<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

const user = { id: "1", name: "Ada", age: 28 };

const name = getValue(user, "name");
// name: string

const age = getValue(user, "age");
// age: number

这里 K extends keyof T 限制 key 必须来自对象本身，T[K] 则能推导出对应字段的值类型。

typeof：从值反推类型

很多时候配置是先写出来的，类型希望从配置自动推导，而不是手写一遍。

1
2
3
4
5
6
7
8
9
10
11

const routes = {
  home: "/",
  about: "/about",
  dashboard: "/dashboard",
};

type RouteName = keyof typeof routes;
// "home" | "about" | "dashboard"

type RoutePath = (typeof routes)[RouteName];
// string

如果希望 value 保持字面量类型，可以加 as const：

1
2
3
4
5
6
7
8

const routes = {
  home: "/",
  about: "/about",
  dashboard: "/dashboard",
} as const;

type RoutePath = (typeof routes)[keyof typeof routes];
// "/" | "/about" | "/dashboard"

as const 会把对象变成只读，并把字符串值收窄成字面量类型。

satisfies：校验结构但保留字面量类型

satisfies 是一个非常适合写配置的语法。它既能检查对象是否符合某个类型，又不会像类型注解那样把字面量信息抹掉。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

type MenuItem = {
  label: string;
  path: string;
  external?: boolean;
};

const menus = {
  ai: {
    label: "AI",
    path: "https://devflow.aiyly.com/",
    external: true,
  },
  blog: {
    label: "Blog",
    path: "/",
  },
} satisfies Record<string, MenuItem>;

type MenuKey = keyof typeof menus;
// "ai" | "blog"

如果写错字段，TypeScript 会报错；同时 menus 自己仍然保留精确的 key。

适合使用 satisfies 的场景：

• 菜单配置
• 路由配置
• 权限配置
• 表单 schema
• 状态机配置
• 多语言文案配置

映射类型：批量改造对象结构

映射类型可以遍历一个对象类型的所有 key。

1
2
3
4
5
6
7
8
9
10
11

type User = {
  id: string;
  name: string;
  email: string;
};

type Nullable<T> = {
  [K in keyof T]: T[K] | null;
};

type NullableUser = Nullable<User>;

NullableUser 等价于：

1
2
3
4
5

type NullableUser = {
  id: string | null;
  name: string | null;
  email: string | null;
};

也可以让所有字段变成可选：

1
2
3

type PartialBy<T, K extends keyof T> = Omit<T, K> & Partial<Pick<T, K>>;

type UserDraft = PartialBy<User, "email">;

这个类型表示：除了 email 可选，其他字段保持原样。

条件类型：根据输入类型计算输出类型

条件类型长得像三元表达式：

1
2
3
4
5
6
7

type IsString<T> = T extends string ? true : false;

type A = IsString<string>;
// true

type B = IsString<number>;
// false

更实用的例子是根据 API 响应类型提取数据：

1
2
3
4
5
6
7
8
9

type ApiResponse<T> =
  | { success: true; data: T }
  | { success: false; message: string };

type ExtractData<T> = T extends { success: true; data: infer D } ? D : never;

type UserResponse = ApiResponse<{ id: string; name: string }>;
type UserData = ExtractData<UserResponse>;
// { id: string; name: string }

这里用到了 infer。

infer：在条件类型里提取局部类型

infer 可以理解成“在类型匹配时临时声明一个变量”。

提取 Promise 里的值：

1
2
3
4
5
6
7

type UnwrapPromise<T> = T extends Promise<infer R> ? R : T;

type A = UnwrapPromise<Promise<string>>;
// string

type B = UnwrapPromise<number>;
// number

提取数组元素：

1
2
3
4
5

type ArrayItem<T> = T extends Array<infer Item> ? Item : never;

type UserList = Array<{ id: string; name: string }>;
type UserItem = ArrayItem<UserList>;
// { id: string; name: string }

提取函数返回值：

1
2
3
4
5
6
7
8

type FnReturn<T> = T extends (...args: any[]) => infer R ? R : never;

function createUser() {
  return { id: "1", name: "Ada" };
}

type CreatedUser = FnReturn<typeof createUser>;
// { id: string; name: string }

TypeScript 内置的 ReturnType、Parameters、Awaited 等工具类型背后也大量使用了类似思路。

模板字面量类型：拼接字符串类型

模板字面量类型可以基于字符串字面量生成新的字符串类型。

1
2
3
4
5

type Method = "GET" | "POST" | "PUT" | "DELETE";
type Path = "/users" | "/posts";

type ApiKey = `${Method} ${Path}`;
// "GET /users" | "GET /posts" | "POST /users" | ...

可以用它约束事件名：

1
2
3
4
5
6
7
8
9
10

type Model = "user" | "post" | "comment";
type EventName = `${Model}:created` | `${Model}:updated` | `${Model}:deleted`;

function emit(event: EventName) {
  console.log(event);
}

emit("user:created");
emit("post:updated");
// emit("user:create"); // 类型错误

在实际项目里，它适合做：

• 事件名约束
• API key 约束
• CSS token 名称
• 权限标识
• 表单字段路径

工具类型：不要重复造轮子

TypeScript 内置了很多常用工具类型。

1
2
3
4
5
6

type User = {
  id: string;
  name: string;
  email: string;
  password: string;
};

选出一部分字段：

1

type PublicUser = Pick<User, "id" | "name">;

排除一部分字段：

1

type SafeUser = Omit<User, "password">;

全部可选：

1

type UserPatch = Partial<User>;

全部必填：

1

type RequiredUser = Required<User>;

只读：

1

type ReadonlyUser = Readonly<User>;

构造对象字典：

1

type UserMap = Record<string, User>;

提取函数参数：

1
2
3
4

function updateUser(id: string, data: Partial<User>) {}

type UpdateUserParams = Parameters<typeof updateUser>;
// [id: string, data: Partial<User>]

提取异步函数返回值：

1
2
3
4
5
6

async function fetchUser() {
  return { id: "1", name: "Ada" };
}

type FetchUserResult = Awaited<ReturnType<typeof fetchUser>>;
// { id: string; name: string }

类型守卫：把运行时判断变成类型信息

有时候数据来自接口，TypeScript 并不知道它到底是什么结构。这时可以写类型守卫。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

type User = {
  id: string;
  name: string;
};

function isUser(value: unknown): value is User {
  return (
    typeof value === "object" &&
    value !== null &&
    "id" in value &&
    "name" in value
  );
}

function handleValue(value: unknown) {
  if (isUser(value)) {
    return value.name;
  }

  return "unknown";
}

value is User 告诉 TypeScript：如果函数返回 true，那么这个值就可以当作 User 使用。

类型守卫适合处理：

• 接口返回的 unknown 数据
• localStorage 读取的数据
• postMessage 数据
• 第三方 SDK 回调
• JSON.parse 的结果

const 泛型：保留更精确的字面量类型

TypeScript 5.0 引入了 const type parameters，可以让泛型函数保留更精确的字面量类型。

普通泛型：

1
2
3
4
5
6
7
8

function defineRoutes<T extends Record<string, string>>(routes: T) {
  return routes;
}

const routes = defineRoutes({
  home: "/",
  about: "/about",
});

很多时候这样已经够用。如果希望参数推导更接近 as const，可以使用 const 泛型：

1
2
3
4
5
6
7
8
9
10
11

function defineRoutes<const T extends Record<string, string>>(routes: T) {
  return routes;
}

const routes = defineRoutes({
  home: "/",
  about: "/about",
});

type RoutePath = (typeof routes)[keyof typeof routes];
// "/" | "/about"

这在封装配置函数时很方便，比如：

• defineRoutes
• defineMenu
• definePermissions
• defineStore
• defineEvents

实战：封装一个类型安全的请求函数

假设后端接口都有统一返回格式：

1
2
3

type ApiResult<T> =
  | { success: true; data: T }
  | { success: false; message: string };

定义接口映射：

1
2
3
4
5
6
7
8
9
10

type ApiSchema = {
  "GET /api/users": {
    query: { page: number };
    response: { id: string; name: string }[];
  };
  "POST /api/users": {
    body: { name: string; email: string };
    response: { id: string };
  };
};

提取请求参数：

1
2
3
4
5
6
7
8

type RequestConfig<K extends keyof ApiSchema> =
  ApiSchema[K] extends { query: infer Q }
    ? { query: Q }
    : ApiSchema[K] extends { body: infer B }
      ? { body: B }
      : never;

type ResponseData<K extends keyof ApiSchema> = ApiSchema[K]["response"];

封装请求函数：

1
2
3
4
5
6
7
8
9
10
11
12
13

async function request<K extends keyof ApiSchema>(
  key: K,
  config: RequestConfig<K>,
): Promise<ApiResult<ResponseData<K>>> {
  const [method, url] = key.split(" ");

  const response = await fetch(url, {
    method,
    body: "body" in config ? JSON.stringify(config.body) : undefined,
  });

  return response.json();
}

调用时就能自动推导参数和返回值：

1
2
3
4
5
6
7
8
9
10

const result = await request("POST /api/users", {
  body: {
    name: "Ada",
    email: "ada@example.com",
  },
});

if (result.success) {
  result.data.id;
}

如果传错参数，编译期就会报错：

1
2
3
4
5
6
7

request("POST /api/users", {
  // query: { page: 1 }, // 类型错误，POST /api/users 需要 body
  body: {
    name: "Ada",
    email: "ada@example.com",
  },
});

这类模式很适合小中型项目。如果项目更大，可以继续演进成基于 OpenAPI、tRPC 或 RPC schema 的方案。

实战：用类型约束状态机

前端经常会遇到状态流转，比如任务状态、订单状态、工作流步骤。

先定义状态和事件：

1
2
3
4
5
6
7
8

type Status = "pending" | "running" | "waiting_user_confirm" | "succeeded" | "failed";

type Event =
  | { type: "start" }
  | { type: "confirm" }
  | { type: "success" }
  | { type: "fail"; message: string }
  | { type: "retry" };

定义允许的流转：

1
2
3
4
5
6
7

const transitions = {
  pending: ["running"],
  running: ["waiting_user_confirm", "succeeded", "failed"],
  waiting_user_confirm: ["running"],
  succeeded: [],
  failed: ["pending"],
} as const satisfies Record<Status, readonly Status[]>;

提取某个状态允许流转到的状态：

1
2

type Transitions = typeof transitions;
type NextStatus<S extends Status> = Transitions[S][number];

封装流转函数：

1
2
3
4
5
6
7

function transition<S extends Status>(from: S, to: NextStatus<S>) {
  return to;
}

transition("pending", "running");
transition("failed", "pending");
// transition("succeeded", "running"); // 类型错误

这样可以把一部分状态机规则提前放到类型系统里。当然，运行时仍然要做校验，因为用户输入和服务端数据不一定可信。

什么时候不该写复杂类型

TypeScript 高级类型不是越复杂越好。类型系统的目标是帮团队减少错误，而不是制造阅读成本。

不建议过度使用复杂类型的场景：

• 业务逻辑本身很简单。
• 类型写出来比实现还难懂。
• 错误提示已经很难读。
• 团队成员很难维护。
• 运行时校验才是真正关键点。

一个比较实用的判断标准是：如果这个类型能明显减少重复、约束关键业务规则、提升调用体验，就值得写；如果只是为了少写几行普通类型，可能没必要。

总结

TypeScript 的高级能力可以分成几类：

• keyof、typeof、as const：从值和对象中提取类型。
• 泛型约束：表达输入和输出之间的关系。
• 映射类型：批量改造对象字段。
• 条件类型和 infer：根据输入类型计算输出类型。
• 模板字面量类型：约束有规律的字符串。
• satisfies：校验配置结构，同时保留精确字面量类型。
• 类型守卫：把运行时判断转成类型收窄。
• 工具类型：复用 TypeScript 内置能力。

真正写项目时，不需要为了“高级”而高级。最好的类型设计，是让业务代码更少出错、更容易补全、更容易重构，并且让下一位维护者能看懂。

前端项目从早期的「一个 HTML + 几个 JS 文件」发展到今天的组件化、模块化、TypeScript、CSS 预处理器、图片字体资源管理、代码分割等复杂形态，浏览器已经无法直接高效处理所有源码形态。
打包工具的核心价值是：把开发态代码转换为浏览器可高效运行的生产态资源。

打包工具主要解决四类问题：

1. 语法转换：TypeScript、JSX、Sass/Less 等需要编译。
2. 模块组织：把 ESM/CommonJS/动态导入统一构建成可运行产物。
3. 性能优化：压缩、Tree Shaking、代码分割、缓存优化。
4. 开发体验：热更新（HMR）、本地服务、错误提示、插件生态。

二、常见前端打包工具全景

2.1 Webpack

Webpack 是一个功能非常全面的构建工具，适合复杂中大型项目，生态成熟。

特点：

• 配置能力强，可深度定制
• Loader + Plugin 机制强大
• 社区资料多，历史包袱也较重
• 冷启动和构建速度通常不如新一代工具

适用场景：历史项目、需要高度定制的企业级项目、复杂微前端场景。

2.2 Vite

Vite 的思路是「开发态利用浏览器原生 ESM，生产态再用 Rollup 打包」，因此开发体验非常快。

特点：

• 启动快，HMR 快
• 配置简洁，上手成本低
• 对 Vue/React 支持完善
• 生产构建依赖 Rollup，产物质量高

适用场景：现代前端项目首选，尤其是 Vue3/React 新项目。

2.3 Rollup

Rollup 更偏向于「库打包」：产物干净、Tree Shaking 效果好。

特点：

• 输出体积通常较小
• 对 ESM 支持优秀
• 插件生态也较成熟
• 应用级能力相对 Webpack 略弱

适用场景：npm 包、组件库、工具库构建。

三、核心能力拆解：打包工具到底在做什么

3.1 模块依赖分析（Dependency Graph）

打包器从入口文件（如 main.ts）开始，递归分析所有 import，构建依赖图。
最终输出多个 chunk（代码块），实现按需加载。

3.2 代码转换（Transpile）

• TS/JSX -> JS
• Sass/Less -> CSS
• 新语法降级（兼容旧浏览器）

常见工具链：Babel、SWC、esbuild。

3.3 资源处理（Assets）

处理图片、字体、SVG、音视频等静态资源，生成带 hash 的文件名，便于缓存控制。

3.4 代码分割（Code Splitting）

把非首屏代码拆分，结合路由懒加载：

1

const UserPage = () => import("./pages/UserPage");

这样首屏体积更小，用户首次打开更快。

3.5 Tree Shaking

移除未使用代码，减少包体积。
前提是尽量使用 ESM，并避免副作用污染（sideEffects 配置）。

四、Webpack 与 Vite：如何选型

结论建议：

• 新项目：优先 Vite。
• 强依赖 Webpack 生态或深度定制：继续 Webpack。
• 做组件库：优先 Rollup / Vite（库模式）。

五、实战配置建议（高频可落地）

5.1 路由级懒加载

优先拆路由页面，而不是过度细粒度拆分，避免请求过多。

5.2 合理设置缓存策略

输出文件加内容哈希：

• app.[contenthash].js
• vendor.[contenthash].js

浏览器可长期缓存不变资源，仅更新变更文件。

5.3 第三方依赖分包

把稳定且体积大的依赖（如 react、vue、lodash）抽离到单独 chunk，提升缓存命中率。

5.4 生产环境开启压缩与去注释

• JS 压缩：Terser / esbuild minify
• CSS 压缩：cssnano
• 去 sourceMap（视排障需求而定）

5.5 分析包体积

定期用分析工具看体积分布，避免无意识膨胀：

• webpack-bundle-analyzer
• rollup-plugin-visualizer
• vite-bundle-visualizer

六、Vite 示例配置（React 项目）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  build: {
    sourcemap: false,
    rollupOptions: {
      output: {
        manualChunks: {
          react: ["react", "react-dom"],
        },
      },
    },
  },
});

这段配置做了两件常见优化：

1. 关闭生产 sourceMap（减小产物）
2. 手动拆分 React 相关依赖（提升缓存利用）

七、前端打包常见误区

1. 只追求“打包速度快”，忽略产物质量和可维护性。
2. 过度拆包，导致请求数过多，反而变慢。
3. 忽略缓存策略，每次发布都让用户全量下载。
4. 未做包体积监控，项目长期演进后体积失控。
5. 无迁移评估就切工具，造成插件兼容和团队成本问题。

八、总结

打包工具并不是“选一个就结束”，而是一个持续优化的工程实践：
选型 + 配置 + 监控 + 迭代，四步缺一不可。

如果你是新项目，建议从 Vite 开始；如果是历史复杂项目，Webpack 仍然可靠；如果你在做库，Rollup 往往更合适。
真正决定性能上限的，不只是工具本身，而是你对模块拆分、缓存策略和构建流程的整体设计能力。

渲染架构是同步递归，无法中断。

react16

• 革命性升级：Fiber架构：把递归改成链表结构，可中断渲染，为并发渲染打好基础。

• 除了底层的重构，React 16 也带来了一系列直接影响开发方式的新特性。

  特性	说明	解决了什么问题
  Error Boundaries (错误边界)	static getDerivedStateFromError() 和 componentDidCatch() 两个生命周期方法，创建一个能捕获其子组件树中 JavaScript 错误的组件	局部容错：之前组件内的一个 JS 错误会导致整个 React 应用崩溃，现在可以用错误边界包裹特定区域，显示一个降级的备用 UI，而不会影响应用的其他部分
  Portals (传送门)	ReactDOM.createPortal(child, container) 允许将子节点渲染到父组件 DOM 层级之外的 DOM 节点中	跳出 DOM 层级限制：完美解决了模态框（Modal）、提示框（Tooltip）、悬浮菜单等需要从视觉上“突破”父容器（如 overflow: hidden）的组件的渲染问题
  render 方法的新返回类型	组件的 render 函数现在可以直接返回数组和字符串，而不再强制要求被一个单一的根元素包裹	告别“Div 地狱”：避免了在组件外层套一个无意义的 ，让 DOM 结构更干净，尤其在返回一组并列元素时非常有用。React 16.2 后更是推荐使用 <React.Fragment> 或 <> </> 语法，语义更清晰
  React.memo	一个高阶组件，用于函数组件，通过浅层比较 props 来决定是否跳过重新渲染，从而提升性能	函数组件的性能优化：此前只有类组件可以通过继承 PureComponent 实现类似功能，React.memo 将这一性能优化能力赋予了函数组件。

react17

是一个“没有新特性”的版本，过渡版本，重写时间系统。为了降低 React 自身的升级门槛，为未来的版本（尤其是 React 18 的并发特性）铺平道路

react18

1）并发模式

可中断，可恢复，可丢弃，优先响应用户交互

2）自动批处理

以前只有react事件才会批处理，比如onClick onChange。
现在所有异步都可批处理：fetch/setTimeOut/promise 批处理一次render。

3）Transitions（过渡更新） 优先级控制

区分紧急更新和非紧急更新，API:startTransition，useTransition。
示例：

1
2
3
4
5
6
7
8
9
10

// hooks用法 isPending：表示是否有过渡更新正在执行
const [isPending, startTransition] = useTransition();
function handleChange(e) {
  // 优先更新input ->高优先级
  setInput(e.target.value);
  // 搜索列表慢慢渲染 ->低优先级
  startTransition(() => {
    setList(filterList(e.target.value));
  });
}

4）新的hooks

• useId:生成稳定性唯一ID,完美支持SSR和无障碍访问。

• useDeferredValue（延迟渲染某些值）:
  适用于搜索，大列表
  例子：

  1 2 3

  // input实时更新 列表慢一点更新 const deferredText = useDeferredValue(text) <MySlowList text={deferredText} />

• useTransition（以上有说到用法）

• useSyncExternalStore：安全订阅外部数据源
  react18的并发模式可能会导致状态撕裂，ui显示数据不一致，所以外部状态源例如redux，zustand要保证并发模式的一致性。

5）Suspense SSR支持 + Streaming

suspense支持服务器渲染，以前 ssr必须等全部数据，现在:

1
2
3

组件1 ready -> 先返回
组件2 loading -> fallback
组件2 ready -> 再流式返回

Nextjs中的运用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import { Suspense } from "react";

// 这是一个需要异步获取数据的组件
async function Comments() {
  // 模拟慢速数据请求
  const res = await fetch("https://api.example.com/comments", {
    cache: "no-store",
  });
  const comments = await res.json();
  return (
    <ul>
      {comments.map((comment) => (
        <li key={comment.id}>{comment.text}</li>
      ))}
    </ul>
  );
}

export default function BlogPost() {
  return (
    <div>
      <h1>我的博客文章</h1>
      <p>这是文章的快速主体部分，会立即发送到浏览器。</p>

      {/* 用 Suspense 包裹评论组件 */}
      <Suspense fallback={<div>正在加载评论...</div>}>
        <Comments />
      </Suspense>
    </div>
  );
}

react19(核心是全栈化)

19引入Server components和Actions，让React从前端框架演进为全栈解决方案。
1️⃣ Server Components：组件可以在服务端执行

2️⃣ Actions（革命性）：可直接在组件里面写后端逻辑，不用fetch：

1

<form action={async (formData) => {}}>

3️⃣ use hook（直接 await）

1
2
3
4
5
6
7

import { use } from "react";

function Page() {
  const data = use(fetch("/api/data").then((res) => res.json()));

  return <div>{data.name}</div>;
}

4️⃣ 表单能力增强: useActionState useFormStatus
React 以前处理表单提交非常麻烦,需要 loading / error / state 手动管理

1）useActionState的用法 (管理表单 action 执行后的状态。)

以前写法

1
2

const [loading, setLoading] = useState(false);
const [data, setData] = useState(null);

现在写法

1
2

// action为表单提交的函数，initialState为初始状态 state（action返回的数据）, formAction（绑定给 form）, isPending（是否正在提交）
const [state, formAction, isPending] = useActionState(action, initialState);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import { useActionState } from "react";

async function submitForm(prevState, formData) {
  const name = formData.get("name");

  return {
    message: `Hello ${name}`,
  };
}

export default function Form() {
  const [state, formAction, isPending] = useActionState(submitForm, {
    message: "",
  });

  return (
    <form action={formAction}>
      <input name="name" />

      <button disabled={isPending}>Submit</button>

      <p>{state.message}</p>
    </form>
  );
}

2）useFormStatus的用法 (获取表单的提交状态)

用法示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// SubmitButton组件
import { useFormStatus } from "react-dom";

function SubmitButton() {
  const { pending } = useFormStatus();

  return (
    <button disabled={pending}>{pending ? "Submitting..." : "Submit"}</button>
  );
}
// Form组件
function Form() {
  return (
    <form action={saveUser}>
      <input name="name" />

      <SubmitButton />
    </form>
  );
}

1.1 预加载 (Preloading)

定义：在用户需要之前，提前加载资源（JS、CSS、图片等）并缓存到浏览器内存中，但不执行也不渲染页面。

本质：资源的提前获取，而非页面的提前准备。

类比：餐厅后厨提前备好食材（洗好、切好），但还没下锅炒。

1.2 预渲染 (Prerendering)

定义：不仅加载资源，还在后台完整执行并渲染整个页面（包括JS、DOM、CSSOM），完成后置于隐藏标签页，用户点击时直接切换显示。

本质：页面的完全准备就绪。

类比：餐厅直接把菜炒好保温，客人一点就上桌。

二、技术实现对比

三、预加载的具体实现

3.1 HTML标签方案（最推荐）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<!-- 1. preload：当前页面关键资源（高优先级） -->
<link rel="preload" href="critical.css" as="style" />
<link rel="preload" href="hero-image.jpg" as="image" />
<link rel="preload" href="main.js" as="script" />

<!-- 2. prefetch：下一页资源（低优先级，空闲时加载） -->
<link rel="prefetch" href="page2.js" as="script" />
<link rel="prefetch" href="next-page.css" as="style" />

<!-- 3. preconnect：提前建立连接 -->
<link rel="preconnect" href="https://api.example.com" />

<!-- 4. dns-prefetch：DNS预解析（preconnect降级方案） -->
<link rel="dns-prefetch" href="https://cdn.example.com" />

3.2 动态JS预加载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// 预加载图片
const preloadImage = (url) => {
  const img = new Image();
  img.src = url;
};

// 预加载脚本（利用prefetch）
const preloadScript = (url) => {
  const link = document.createElement("link");
  link.rel = "prefetch";
  link.href = url;
  document.head.appendChild(link);
};

// 智能预加载（用户悬停时）
let timer;
linkElement.onmouseenter = () => {
  timer = setTimeout(() => {
    import("./heavy-component.js"); // 动态导入
  }, 100);
};

3.3 框架集成

React + Webpack：

1
2
3
4
5
6
7
8

// 使用webpack魔法注释
const Profile = lazy(
  () =>
    import(
      /* webpackPrefetch: true */
      "./Profile"
    ),
);

Next.js：

1
2
3
4
5

// 自动prefetch视口内的Link（生产环境）
<Link href="/about">About</Link>

// 手动控制
<Link href="/about" prefetch={false}>About</Link>

四、预渲染的实现方案

4.1 Speculation Rules API（现代标准）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<script type="speculationrules">
  {
    "prerender": [
      {
        "source": "list",
        "urls": ["next-page.html", "checkout.html"],
        "requires": ["anonymous-client-ip-when-cross-origin"]
      }
    ],
    "prefetch": [
      {
        "source": "list",
        "urls": ["likely-next.html"]
      }
    ]
  }
</script>

4.2 服务端预渲染

静态生成（SSG）：在构建时生成完整的 HTML 页面，适合静态内容。通过 getStaticProps 和 getStaticPaths 实现，支持增量静态再生（ISR）以定期更新页面内容。

目前 JavaScript 主要有两种模块规范：

• CommonJS（CJS）
• ECMAScript Modules（ESM）

一、CommonJS（CJS）

CommonJS 是 Node.js 早期使用的模块规范。

在 ES6 模块化出现之前，Node.js 使用 CommonJS 解决模块化问题。

1 导出模块

1
2
3
4

module.exports = {
  add,
  sub
}

或

1

exports.add = add

tips：

• module.exports 是真正的导出对象
• exports 只是 module.exports 的引用

2 导入模块

1

const math = require('./math')

tips：
require() 会加载模块并返回 module.exports。

3 CommonJS 特点

1️⃣ 同步加载

1

const module = require('./module')

加载流程：

读取文件↓执行文件↓返回 exports

特点：

• 同步执行
• 适合服务器环境

2️⃣ 运行时加载

require() 本质是函数，因此可以动态执行。

1
2
3

if (condition) {
  const module = require('./module')
}

3️⃣ 值拷贝

CommonJS 导出的是 值的拷贝。

1
2
3
4
5
6

// a.js
let count = 0

module.exports = {
  count
}

1
2
3
4

// b.js
const { count } = require('./a')

console.log(count)

如果 a.js 里的 count 改变：

b.js 不会自动更新

4️⃣ 模块缓存

Node.js 会缓存加载过的模块。

1
2

require('./a')
require('./a')

模块只会执行一次。

缓存机制：

Module Cache

二、ESM（ECMAScript Modules）

ESM 是 ES6（2015）官方模块化规范。

现在浏览器和 Node.js 都支持。

1 导出模块

命名导出

1
2

export const add = () => {}
export const sub = () => {}

默认导出

1

export default function add() {}

2 导入模块

命名导入

1

import { add } from './math.js'

默认导入

1

import add from './math.js'

全部导入

1

import * as math from './math.js'

3 ESM 特点

1️⃣ 静态分析（编译时解析）

ESM 的依赖关系在 编译阶段就能确定。

1

import { add } from './math'

限制：

• 必须写在顶层
• 不能写在 if / for / function 中

错误示例：

1
2
3

if (true) {
  import { add } from './math'
}

2️⃣ 异步加载

浏览器加载模块时，并行下载模块，适合前端环境。

3️⃣ 实时绑定（引用）

ESM 导出的是 引用（Live Binding）。

1
2
3
4
5
6

// a.js
export let count = 0

setTimeout(() => {
  count++
}, 1000)

1
2
3
4

// b.js
import { count } from './a'

console.log(count)

count 会随着 a.js 的变化而变化。

4️⃣ 支持 Tree Shaking

由于 ESM 是 静态结构，打包工具可以删除未使用代码。

1
2

export const add = () => {}
export const sub = () => {}

如果只使用：

1

import { add } from './math'

打包时，sub 会被删除。

三、CJS vs ESM 对比

四、Node.js 中使用 ESM

Node.js 默认使用 CommonJS。如果要使用 ESM，有两种方式：

方式一：package.json

1
2
3

{
  "type": "module"
}

之后 .js 文件默认使用 ESM。

方式二：使用 .mjs

index.mjs

五、CJS 和 ESM 互相导入

在 Node.js 中，两种模块系统可能共存。

1 ESM 导入 CJS

1

import pkg from './cjs.js'

默认导出为 module.exports。

2 CJS 导入 ESM

不能直接使用 require()，需要：

1

import('./esm.js')

动态导入。

六、ESM 对前端工程化的意义

现代打包工具更偏向使用 ESM，例如：

• Vite
• Rollup
• ESBuild
• Next.js

原因如下：

1 Tree Shaking

删除未使用代码。

2 静态依赖分析

可以在编译阶段构建依赖图。

3 更好的代码分割

1

import('./module')

七、总结

CommonJS 和 ESM 的区别：
CommonJS 是 Node.js 早期使用的模块规范，使用 require 和module.exports，模块是同步加载，运行时解析，导出的是值拷贝。
ESM 是 ES6 官方模块规范，使用 import 和export，模块在编译阶段进行静态分析，支持异步加载，导出的是引用，并且支持Tree Shaking。

现代前端构建工具（如 Vite、Rollup）通常优先使用ESM，因为它可以在构建阶段进行更好的优化。

SSE用法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// 前端使用 EventSource
const eventSource = new EventSource("/api/stream");

// 监听消息
eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log("收到推送:", data);
};

// 监听自定义事件（如果服务端设置了 event 字段）
eventSource.addEventListener("notification", (event) => {
  console.log("新通知:", event.data);
});

// 错误处理（浏览器会自动重连）
eventSource.onerror = () => {
  console.log("连接异常，浏览器会自动重连");
};

webSocket用法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

// 1. 创建连接
const ws = new WebSocket("ws://localhost:3000"); // ws:// 非加密，wss:// 加密

// 2. 连接打开
ws.onopen = () => {
  console.log("✅ WebSocket 连接已建立");

  // 发送消息
  ws.send(
    JSON.stringify({
      type: "message",
      content: "Hello Server!",
    }),
  );
};

// 3. 接收消息
ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log("📨 收到服务端消息:", data);

  // 处理不同类型消息
  switch (data.type) {
    case "pong":
      console.log("心跳响应");
      break;
    case "notification":
      console.log("通知:", data.content);
      break;
    default:
      console.log("普通消息:", data);
  }
};

// 4. 错误处理
ws.onerror = (error) => {
  console.error("❌ WebSocket 错误:", error);
};

// 5. 连接关闭
ws.onclose = (event) => {
  console.log("🔌 WebSocket 连接已关闭", event.code, event.reason);
  // 尝试重连...
};

// 6. 主动关闭连接
// ws.close(1000, '正常关闭');

心跳机制

心跳机制是一种用于保活和探测连接状态的技术。前端通过websocket或长轮训场景因为中间网络设备（如网关）会长时间没有数据交互的闲置连接，导致“假死”的状态。

解决：前端定期发送ping数据，服务器返回pong，如连接多次无响应，前端判定连接已断开，主动执行重连。

之前的http请求已经认识接触了很多，GET HEAD PUT DELETE POST OPTIONS。今天重点介绍一下options请求我也是第一次接触到。发现：在网络调试时，发现每个请求在发出之前都会先发送一个options请求，第二个才是正常的请求。

什么是options请求？

官方解释：HTTP的options方法是用于获取目的资源所支持的通信选项。客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法。

通俗易懂的来说，就是可以用options请求来嗅探某个请求在对应的服务器中都支持哪种请求方法。

若请求成功，则它会在HTTP头中包含一个名为”Allow”的头，值是所支持的方法，如：”GET,POST”。

HTTP协议中的其他常见请求方式

1. GET：GET发送一个请求来获取服务器上的一个资源。资源通过一组HTTP头和呈现的数据（HTML文本、图片、视频等）返回给客户端。
2. POST：向服务器提交数据
3. PUT：跟POST极为相似，理论上都是向服务器提交数据，但他们之间有一个重要的区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。
4. HEAD：跟GET很相似，但区别在于，HEAD不返回资源的主体部分，也就是不含有呈现的数据，而仅仅是HTTP头信息。
5. DELETE：删除某个资源
6. OPTIONS

背景：HTTP协议本身是无状态的。什么是无状态呢，就是服务器本身无法判断用户身份。Cookie实际上是一小段文本信息（key-value格式）。客户端向服务端发起请求，如果服务器需要记录该用户的状态，就使用response向客户端浏览器颁发一个Cookie。客户端的浏览器就会把此Cookie保存起来。当浏览器再次请求该网站时，浏览器把请求的网址连同该Cookie一并提交给服务器，服务器检查Cookie，以此来辨别用户状态。

cookie使用过程：

1. 浏览器向服务器发起请求
2. 服务器响应时，会发送Set-Cookie响应头；浏览器会把这个头写入Cookie。
3. Cookie到期前，浏览器发送该域下的所有请求，都会带上这个Cookie

httponly

背景：XSS漏洞的网站中输入(传入)恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。

解释：指定该Cookie无法通过JavaScript脚本拿到，主要是Document.cookie属性。

作用：Cookie无法通过js脚本拿到。 防止了XSS攻击，窃取Cookie内容。给Cookie设置httponly可增加Cookie的安全性。

httponly的使用：
response.setHeader("Set-Cookie","deniro=1; Path=/;Domain=www.test.com;" + "Max-Age=30;HTTPOnly");

samesite

背景：防止 CSRF攻击（CSRF 攻击：往往用来存储用户的身份信息，恶意网站可以设法伪造带有正确 Cookie 的 HTTP 请求）和用户追踪。

解释：Cookie 的SameSite属性用来限制第三方 Cookie，从而减少安全风险。

Samesite的值：

• Strict：

  最为严格，完全禁止第三方Cookie，跨站点时，任何情况下都不会发送Cookie。

  Set-Cookie: CookieName=CookieValue; SameSite=Strict;

  注：该规则过于严格，可能给用户造成非常不友好的体验。比如当前网页有一个GitHub链接，用户点击跳转就不会带有GitHub的Cookie，都是未登录状态。

• Lax:

  规则稍稍放宽，大多数情况下也是不发送第三方Cookie，但是导航到目标网址的GET请求除外(链接，预加载请求，GET 表单)。

  Set-Cookie: CookieName=CookieValue; SameSite=Lax;

• None:

  Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

  有效设置：
  Set-Cookie: widget_session=abc123; SameSite=None

  无效设置：
  Set-Cookie: widget_session=abc123; SameSite=None; Secure

1. 同源策略
   网站的安全模式源于同源策略，web浏览器允许第一个进入web页面中的脚本访问页面中的数据，前提是两个web页面都具有相同的源。同源策略防止一个页面的恶意脚本通过该页面的文档访问另一个页面的敏感数据。 安全风险例子：假如你正在访问银行系统，未注销的情况下跳转到另外一个站点，则该站点如果注入了一些恶意脚本进行交易操作。
2. 网页安全漏洞——xss攻击
   在一些情况下，用同源策略，限制县太强，其实不太友好。比如说在大型网站的各个子域下进行一些数据操作，开发过程中用同源策略就有些不太方便；这个时候，就想着利用一些技术放宽一些策略。但是xss攻击可通过欺骗网站来绕过同源策略；通过寻找将恶意脚本注入网页，攻击者可以获得对敏感页面内容，会话cookie以及浏览器代表用户维护的各种其他信息的提升访问权限。 风险例子：盗号、强制发送邮件等等

引入CSP内容安全策略

为了缓解很大一部分的潜在跨脚本问题，浏览器的扩展系统引入了内容安全策略（CSP）的概念。简单来说这技术就是：开发者明确告诉客户端，制定一些严格的策略和规则，那些外部资源是可以加载和执行的，即使攻击者发现漏洞，但是他也是没有办法注入脚本的。

开发人员可以使用这种工具以各种方式锁定其应用程序，降低内容注入漏洞（如跨站点脚本）的风险，并降低其应用程序执行的权限

怎么启用CSP

两种方式：

1. 一种是通过 HTTP 头信息的Content-Security-Policy或Content-Security-Policy-Report-Only的字段

2. 通过网页的标签

CSP的意义

防XSS等攻击的利器。CSP 的实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置。CSP 大大增强了网页的安全性。攻击者即使发现了漏洞，也没法注入脚本，除非还控制了一台列入了白名单的可信主机。

CSP的分类

1. Content-Security-Policy

   配置好并启用后，不符合 CSP 的外部资源就会被阻止加载。

2. Content-Security-Policy-Report-Only

   表示不执行限制选项，只是记录违反限制的行为。它必须与report-uri选项配合使用。

一种约定，是浏览器最核心也是最基本的安全功能。保证用户信息的安全，防止恶意的网站窃取数据。

案例

当有两个网站，网站a和网站b。用户登录网站a后，继续浏览网站b，这时网站b可以拿到网站a的cookie信息，就会泄漏用户的相关隐私信息，也有可能被他人非法使用，甚至破环等等。

含义

同源策略需要同时满足以下三点要求：

1. 协议相同
2. 域名相同
3. 端口相同

注：

http:www.panpan.com与https: www.panpan.com 不同源——协议不同
http:www.panpancom与http:www.mm.com 不同源——域名不同
http:www.panpan.com与http:www.panpan.com:8081 不同源——端口不同

只要不满足其中任意一个要求，就不符合同源策略，就会出现“跨域”。
最常见的形式是使用ajax请求数据。

解决方法

1. postMessage

   html5引用了一个跨文档通信的API，这个API为window对象新增了一个window.postMessage方法，允许跨窗口通信，不论这两个窗口是否同源。

   注释：该方法只解决了前端两个窗口的通信，但无法解决前后台调用的跨域问题

2. jsonp

   网页通过添加一个script元素，向服务器请求json数据，这种方法不受同源策略的限制；服务器收到请求后，将数据放在一个指定的名字回调函数里传回来。

   注释：简单好用，服务器改动小

3. CORS

   Cross-Origin Resource Sharing 跨资源分享，作为W3C的标准，是跨域ajax的根本解决方法，允许任何类型的请求。

   整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

   因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。

   浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

   同时满足以下两个条件，即为简单请求。

    1) 请求方法是以下三种方法之一： HEAD GET POST 2）HTTP的头信息不超出以下几种字段： Accept Accept-Language Content-Language Last-Event-ID Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/        form-data、text/plain

官方解释：重放攻击(Replay Attacks)又称重播攻击、回放攻击，是指攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。重放攻击可以由发起者，也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式盗取认证凭据，之后再把它重新发给认证服务器。重放攻击在任何网络通过程中都可能发生，是计算机世界黑客常用的攻击方式之一。

自己理解：顾名思义，重复的会话请求就是重放攻击。可能是用户自己重复向服务器发起的请求，也有可能是因为请求被攻击者拦截获取，然后重新发送给服务器。

防御手段

防止重放攻击的方法是使用不重数。

1. 加随机数：

   该方法优点是认证双方不需要时间同步，双方记住使用过的随机数，如发现报文中有以前使用过的随机数，就认为是重放攻击。缺点是需要额外保存使用过的随机数，若记录的时间段较长，则保存和查询的开销较大

2. 加时间戳：

   该方法优点是不用额外保存其他信息。缺点是认证双方需要准确的时间同步，同步越好，受攻击的可能性就越小。但当系统很庞大，跨越的区域较广时，要做到精确的时间同步并不是很容易。

3. 加流水号：

   就是双方在报文中添加一个逐步递增的整数，只要接收到一个不连续的流水号报文(太大或太小)，就认定有重放威胁。该方法优点是不需要时间同步，保存的信息量比随机数方式小。缺点是一旦攻击者对报文解密成功，就可以获得流水号，从而每次将流水号递增欺骗认证端。

理解inode要从文件存储讲起，文件存储在硬盘上，硬盘最小的存储单位叫扇区（Sector），每个扇区存储512个字节（相当于0.5KB）。

操作系统读取硬盘的时候，不会一扇一扇的读取，这样效率太低，而是一次性读取多扇区，即一次性读取一个“块”（block）。这种由多个扇区组成的“块”，是文件存储的最小单位。“块”的大小常见是4KB，所以，可得出：8个sector组成一个block。

文件数据都存储在“块”中，那么显然，我们还必须找到一个地方，储存文件的元信息，比如文件的创建者、文件的创建日期、文件的大小等等。这种储存文件元信息的区域就叫做inode（中文：索引节点）。

每个文件都有对应的inode，里面包含了与该文件有关的一些信息。

inode内容

inode包含文件的元信息，具体有以下内容

1. 文件的字节数
2. 文件拥有的User ID
3. 文件的Group ID
4. 文件的读、写、执行权限
5. 文件的时间戳，共有三个：ctime指inode上一次变动的时间，mtime指文件内容上一次变动的时间，atime指文件上一次打开的时间。
6. 链接数，即有多少文件名指向这个inode
7. 文件数据block的位置

查看某个文件的inode信息：stat <文件名>

inode的大小

inode也会消耗硬盘空间，所以硬盘格式化的时候，操作系统自动将硬盘分成两个区域。一个是数据区，存放文件数据；另一个是inode区（inode table），存放inode所包含的信息。

查看每个硬盘分区的inode总数和已经使用的数量，可以使用df命令。

每个inode节点的大小，一般是128字节或256字节。inode节点的总数，在格式化的时候就给定，一般是每1kb或每2kb就设置一个inode。假定在一块1GB的硬盘上，每个inode节点的大小为128字节，每1kb就设置一个inode，那么inode table的大小就会达到128MB，占整块硬盘的12.8%。

inode号码

每个inode都对应一个号码，计算机操作系统是用inode号码来识别不同的文件。

查看某文件对应的inode号码： ls -i Liquid.md

使用 ls -i 来查看某目录文件中所有文件对应的inode号码

硬链接

一般情况下，文件名和inode号码是“一一对应”关系，每个inode号码对应一个文件名。但是，Unix/Linux系统允许，多个文件指向同一个inode。
这意味着，可以用不同的文件名访问同样的内容；对文件内容进行修改，会影响到所有文件名；但是，删除一个文件名，不影响另一个文件名的访问。这种情况被称为“硬链接”（hard link）。

ln命令创建硬链接命令：

ln 源文件 目标文件

软链接

文件a和文件b的inode号码虽然不一样，但文件a的内容是文件b的路径。当读取文件a时，系统会自动将访问者导向文件b。因此，无论打开哪个文件，最终读取的都是文件b。这种情况下，文件a就称为文件b的“软链接”（soft link）

创建软链接命令：

ln -s 源文件或目录 目标文件或目录

inode的特殊作用

由于inode号码与文件名分离，这种机制导致了一些Unix/Linux系统特有的现象。

文件名包含特殊字符，无法正常删除。这时，直接删除inode节点，就能起到删除文件的作用

移动文件或重命名文件，只是改变文件名，不影响inode号码。
打开一个文件以后，系统就以inode号码来识别这个文件，不再考虑文件名。因此，通常来说，系统无法从inode号码得知文件名。第三点使得软件更新变得非常简单，可以在不关闭软件的情况下更新，不需要重启。因为系统通过inode号码，识别运行中的文件，不通过文件名。更新的时候，新版文件以同样的文件名，生成一个新的inode，不会影响到运行中的文件，等到下一次运行这个软件的时候，文件名就自动指向新版本，旧版文件的inode则被收回。

缓存的概念：浏览器缓存就是浏览器对之前访问请求过的文件进行缓存，以便下次访问时重复向服务器再次请求访问，节省带宽，提高访问速度，给服务器减少压力。

1、强缓存：浏览器不会向服务器发送请求，而是直接从本地缓存中读取文件数据

2. 协商缓存：向服务器发送请求，同时服务器最新资源 ETag 和本地资源的 ETag 和 Last-Modified 比较，两种情况：
   • 如果资源已经被更新，返回 200 状态码，浏览器获取最新的服务器资源
     
   • 如果资源没有更新，返回304状态码，浏览器读取本地资源
     

有关缓存的 header 字段信息

可观察以上图：

1. status code（状态码）

• 强缓存：200（from cache）
• 协议缓存 304（not modified） 200

2. 强缓存:

   由 Expires(到期时间)或者 Cache-Control（缓存控制时间，优先级高于 Expires） 这两个字短来控制的

• Expires 为 GMT 格式的时间字符串 代表缓存过期失效时间

• Cache-Control 主要是利用”max-age”来判断缓存过期时间（例如 Cache-Control:max-age=31536000 代表资源有效期为 31536000 秒），还有下面几个比较常用的几个设置值

  • no-cache:不使用本地缓存，需要用协商缓存
  • no-store :直接禁止强缓存，每次用户访问都是去向服务器发送请求
  • public：可以被所有用户缓存
  • private：只能被终端用户缓存

3. 协商缓存

• 第一次请求 请求头上会带上Last-Modified或者Etag字段

• 后续请求 请求头上If-Modified-Since或者If-None-Match字段

• Last-Modified/If-Modified-Since：
  1）. 浏览器第一次发送请求，让服务端在 response header 中返回请求的资源上次更新时间（Last-Modified 的值），浏览器会存下这个时间；

  2）当浏览器下次请求时，request header 中带上 If-Modified-Since(即保存的 Last-Modified 的值)。根据浏览器发送的修改时间和服务端的 wh 修改时间进行比对，一致的话代码资源没有改变，服务端返回正文为空的响应，让浏览器在缓存中读取资源，从而减少请求消耗。

  缺点：Last-Modified精确到秒，如果这个时候，我们一秒内更改了多次文件，那就无法识别了

• ETag/If-None-Match:
  
  发送请求步骤：

  1） 浏览器第一次发送请求得到 Etag 的值，然后爱下一次的请求后 request header 中带上 If-none-match（就是 Etag 保存的值）

  2）通过发送的 ETag 的值和服务器重新生成的 ETag 的值进行比对，如果一致代表资源没有改变，服务器返回的正文为空的响应，让浏览器从缓存中读取资源，从而减少请求消耗。

  Etag工作机制和last-modified基本一样，但Etag解决了last-modified缺点问题，Etag是使用最近修改时间戳的哈希值，具体怎么个运行机制，这点上我还没弄懂。

  缺点：要进行读写操作，所以消耗更大一些，性能比较低。last-modified只需要读取操作

  服务器会优先验证Etag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。

总结

协商缓存受强缓存的影响，强缓存过期了且Cache-Control不为no-store时，是否缓存的问题才由协商缓存决定

安装：yarn add react

引用：import { useEffect } from "react"

useFocusEffect是@react-navigation/native中的hook

安装：yarn add @react-navigation/native

引用：import { useFocusEffect } from "@react-navigation/native"

区别

useFocusEffect类似于React的useEffect hook，唯一的区别是useFocusEffect只在屏幕当前聚焦时运行

发现

最近在做react-native开发Android app时，有一个页面需要做宽屏展示的效果，首先我想到的是用react中的useEffect来做变换页面时切换宽屏。
用了一下，有bug。当在宽屏页面返回到竖屏页面时，当前的竖屏页面却是宽屏。经查询react native中的useFocusEffect可以实时根据屏幕的变化来执行事件。

1
2
3
4
5

import { useFocusEffect } from "@react-navigation/native
import Orientation from "react-native-orientation-locker"
  useFocusEffect(() => {
    Orientation.lockToLandscapeLeft();    
  })

注释：

Orientation（自己命名）：
安装：yarn add react-native-orientation-locker
react-native-orientation-locker（一个react-native模块）包中的，监听设备方向的变化，获取当前方向，锁定到当前方向。

Orientation.lockToPortrait() // lockToPortrait为竖屏显示
Orientation.lockToLandscapeLeft() // lockToLandscapeLeft为宽屏显示

<Input value="hello world" disabled />

样式：

1
2
3
4

const Input = styled.input`
  border: 1px red solid;
  color: black;
`;

Chrome浏览器效果：

Safari浏览器效果：

safari浏览器出现了问题，好像是自身浏览器给input[disabled]加上了opacity样式，尝试在改变opacity得到Chrome浏览器呈现的效果，去掉safari中opacity淡化的样式。

解决方案样式修改：

1
2
3
4
5
6
7
8
9

const Input = styled.input`
  border: 1px red solid;
  color: black;
  :disabled {
    color: black;
    opacity: 1;
    -webkit-text-fill-color: black;
  }
`;

1. 根据屏幕宽度变化来走的响应式函数：calculateWidth
2. 根据屏幕高度变化来走的响应式函数：calculateHeight

1
2
3
4
5
6
7
8
9
10
11

import { Dimensions } from "react-native"
// screenWidth为设计图对应的屏幕宽度
// screenHeight为设计图对应的屏幕高度
const screenWidth:number = 374;
const screenHeight:number = 614;
const calculateWidth = (width: number) => {
  return (Dimensions.get("screen").width / screenWidth) * width
}
const calculateHeight = (height: number) => {
  return (Dimensions.get("screen").height / screenHeight) * height
}

运用：

还原设计图时，相应的数值都用calculateWidth或calculateHeight转化一下：

程序反复调用自身即为递归。

举例：

1
2
3
4

const factorial = (n:number) => {
if(n<=1) return 1;
return n * factorial(n - 1); 
}

我掉入的纠结点误区

总是在纠结这一层函数在干嘛，它调用自身函数后，又做了什么。
这其实掉入了思维误区，现在就想着这每一层功能都是一样的，专注点在一级递归的解决过程就行了。

递归题套路公式

1、确定函数返回值

2、基线条件（确定终止条件，不然会陷入死循环）

3、确定要递归的元素

举例套公式分析（翻转二叉树）

分析：

1、确定函数的返回值：返回二叉树

2、确定终止条件：二叉树左右子树都遍历完，二叉树的value值为空，结束

3、确定要递归的元素：左子树和右子树要递归

1
2
3
4
5
6
7
8
9
10

// 1、返回值: TreeNode 或 null
const invertTree = (root: TreeNode | null): TreeNode | null => {
  // 2、终止条件: root为空
  if (!root) return null;
  return {
    val: root.val,
    left: invertTree(root.right), // 3、要递归的元素：root.right
    right: invertTree(root.left), // 3、要递归的元素：root.left
  };
};

更多递归例题：(斐波那契数列、翻转二叉树、判断是否为对称二叉树、合并二叉树等等)

https://github.com/Sugar-MM/AlgorithmPractice/tree/main/src/recursion

双指针顾名思义就是两个指针，是一个算法思想。但双指针往往是值某几种类型的双指针，而不是仅仅就指两个指针。一般在遍历对象的过程中，使用两个相同方向（快慢指针）或者相反的方向（左右指针）的指针进行遍历。快慢指针和左右端点指针一般是解决双指针一类题的解决方法。
以下对左右指针常见问题的套路总结

左右指针的常见算法和套路

左右端点指针也称碰撞指针，最左侧的索引定义为左指针（left），最右侧的定义为右指针（right），两个指针分别从两头开始向中间进行数组遍历，互相碰面后遍历结束。

图解：

套用公式：

1
2
3
4
5
6
7
8
9
10
11

const fn = (list:number[]) => {
let left = 0;
let right = list.length - 1;
// 遍历数组
while(left <= right) {
left++;
// 一些条件判断和处理
... ...
right++；
}
}

这一般常用来解决的问题：

主要是解决数组或者是字符串中的问题。（例如：移除数组元素，翻转字符串数组，二分查找）

例子：

例1:双指针翻转字符串

1
2
3
4
5
6
7
8
9
10
11
12

const reverseString = (s: string[]): void => {
  let left = 0;
  let right = s.length - 1;
  while (left <= right) {
    if (s[left] !== s[right]) {
      [s[left], s[right]] = [s[right], s[left]];
    }
    left++;
    right--;
  }
  console.log('s:', s);
};

例2: 移除数组元素 给定一个数组 一个val 原地移除数组里等于val的值 返回移除后数组的长度(双指针思想)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

const removeElement = (nums: number[], val: number): number => {
  let left = 0;
  let last = nums.length - 1;
  while (left <= last) {
    if (nums[left] === val) {
      nums[left] = nums[last];
      nums.splice(last, 1);
      last--;
    } else {
      left++;
    }
  }
  console.log(nums);
  return left;
};

例3:两个有序数组的合并

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

const merge2 = (nums1: number[], nums2: number[], m: number, n: number): void => {
  let p = m + n - 1; // p初始值指向 nums1长度为m+n后的数组 最后一位
  let p1 = m - 1; // p1指向nums1原数组的最后一位
  let p2 = n - 1; // p2指向nums2数组的最后一位
  // 空数组判断： 如果p1 或p2其中有一个<0 则 有一个是空数组 则直接就把nums2插入到nums1就可以了
  if (p1 < 0 || p2 < 0) {
    nums1.splice(0, n, ...nums2);
  }
  // p2 指针越界后循环结束
  while (p2 >= 0) {
    // 将nums1[p1]和nums2[p2]的值相比较
    // 大的一方 赋值给nums1[p] p每一次循环都往前移动，p1和p2指针根据谁指的值大 谁往前移一位
    if (nums2[p2] < nums1[p1]) {
      nums1[p] = nums1[p1];
      p--;
      p1--;
    } else {
      nums1[p] = nums2[p2];
      p--;
      p2--;
    }
  }
  console.log('merge2——nums1:', nums1);
};

例4:二分查找

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

const binarySearch = (nums: number[], target: number): number => {
  let left = 0;
  let right = nums.length - 1;
  while (left <= right) {
    const mid = left + (right - left);
    if (target > nums[mid]) {
      left = mid + 1;
    } else if (target < nums[mid]) {
      right = mid - 1;
    } else return mid;
  }
  return -1;
};
binarySearch([-1, 0, 3, 5, 9, 12], 9) //输出4
binarySearch([-1, 0, 3, 5, 9, 12], 1) //输出-1

双指针之左右指针题的gitHub地址：

https://github.com/Sugar-MM/AlgorithmPractice/tree/main/src/doublePointer

git log可以显示所有提交过的版本信息，不包括已经被删除的 commit 记录和 reset 的操作

git reflog显示所有的操作记录，包括提交，回退的操作。一般用来找出操作记录中的版本号，进行回退。

今天就开发中因为提交，回退加切换分支的一系列操作，导致之前版本号用git hist找不到了，然后用git reflog一试，找到了！所以遇到找不回的版本号时，不妨可以试试git reflog