前言
欢迎到我们的交流群一起交流各种前端技术，同时欢迎访问我的 headless 组件库，同时感谢你的 star：
nest.js / hono.js 一起学系列，最终会封装一个通用的架子，例如有鉴权，日志收集，多环境配置等等功能，用两种框架去实现。
之前写了两篇关于这两个框架编程思想相关的
这一篇主要是涉及到我们马上开发前需要具备的一些基础知识，包含：
- 命令行工具使用
- 最佳工程实践（目录规划篇）
- 如何调试
- docker 入门 + 深入 docker 基本原理
命令行上手
全局安装 CLI
建议，全局安装 CLI， 然后试着创建一个项目试试：
npm i -g @nestjs/cli
nest new project-name
后续，你按照命令行提示即可完成项目初始化，然后安装完包，最后看一下 package.json 中 scripts 中的启动命令是什么，启动项目即可。
hono.js 初始化项目是采用：
npm create hono@latest project-name
同样，你按照命令行提示即可完成项目初始化，然后安装对应的包即可，最后看一下 package.json 中 scripts 中的启动命令是什么，启动项目即可。
但是 hono.js 并没有类似 nest 的 cli 管理工具，毕竟 nest 的写法要繁琐很多，所以官方提供了一些快速创建模板的命令。可以通过以下命令查看：
nest --help
最常见的使用 generate 或者 g 来生成模板, 我们可以用 -d 命令，来让 cli 告诉你，你的 generate 或者 g 命令会生成什么文件，咱们来试试，假设我们要创建一个 名字为 user 的 class
nest g class user -d
显示：
CREATE src/user/user.spec.ts (139 bytes)
CREATE src/user/user.ts (21 bytes)
Dry run enabled. No files written to disk.
注意最后一行： No files written to disk. 也就是没有真的把文件写入，而是提示如果你使用nest g class user 可能创建的文件有哪些。
还有，我们有时候不太喜欢测试，可以使用
nest g class user --no-spec
来省去测试文件的创建。
最佳工程实践
我们这里列举一些比较好的工程实践的点，欢迎大家一起讨论。
工程目录
我们采用”约定大于配置“的思想，无论使用什么 node.js 后端框架，我们的目录名尽可能一致。
nest.js 的建议，如果以下目录名意思不清楚没关系，后续学到控制器，service 等等章节的时候，就会明白了：
src/
├── modules/ # 核心：按业务领域划分的模块
│ ├── users/ # 用户模块
│ │ ├── dto/ # 数据传输对象（请求/响应结构）
│ │ ├── entities/ # 数据库实体
│ │ ├── users.controller.ts
│ │ ├── users.service.ts
│ │ └── users.module.ts
│ └── products/ # 产品模块（结构类似用户模块）
├── common/ # 共享资源
│ ├── filters/ # 全局异常过滤器
│ ├── interceptors/ # 拦截器
│ └── guards/ # 守卫
├── config/ # 全局配置
├── database/ # 数据库连接配置
└── app.module.ts # 应用根模块
核心设计原则：
- 功能内聚：与“用户”相关的所有文件（控制器、服务、实体、DTO）都应放在 users 目录下。
- 分层管理：使用 common、core 等目录管理跨模块共享的组件和全局配置。
hono.js 的建议如下，当然 config ,utils 这些比较常见的全局模块也可以提到第一层级，也就是 src 目录下：
src/
├── modules/ # 每个模块独立
│ ├── user/
│ │ ├── routes.ts # 只放路由注册（薄层）
│ │ ├── controller/ # handlers 控制器层
│ │ │ ├── get-user.ts
│ │ │ ├── list-users.ts
│ │ │ ├── create-user.ts
│ │ │ └── update-user.ts
│ │ ├── service/ # 业务逻辑
│ │ │ └── user.service.ts
│ │ ├── repository/ # DB / 外部API
│ │ │ └── user.repo.ts
│ │ ├── middleware/ # 与 user 模块强相关的中间件
│ │ │ └── user-auth.middleware.ts
│ │ ├── validators/ # DTO / 校验器（zod / valibot）
│ │ │ ├── create-user.validator.ts
│ │ │ └── update-user.validator.ts
│ │ ├── dto/ # 请求 / 响应类型
│ │ │ ├── user.dto.ts
│ │ │ └── index.ts
│ │ ├── constants.ts # 与 user 相关的常量
│ │ ├── index.ts # 模块总出口
│ │ └── types.ts # 模块相关类型
│ │
│ ├── product/
│ │ ├── routes.ts
│ │ ├── controller/
│ │ ├── service/
│ │ ├── repository/
│ │ ├── middleware/
│ │ ├── validators/
│ │ └── dto/
│ │
│ └── auth/
│ └── ...
│
├── common/ # 全局复用层（不属于任何模块）
│ ├── app.ts # app 初始化（全局中间件、错误处理）
│ ├── router.ts # 合并 modules 的 routes
│ ├── middlewares/ # 全局中间件
│ ├── config/ # 配置（DB、ENV等）
│ ├── utils/ # 工具
│ ├── errors/ # 全局错误类
│ ├── types/ # 全局类型
│ └── logging/ # 日志系统
| # 也可以把一些重要模块单独放在根目录，例如 config ， log
│
└── index.ts # 启动文件
注意：也可以把一些重要模块单独放在根目录，例如 config ， log等等，看业务需要。
最后，我们可以借鉴一下 angular 团队的一些代码风格指南。例如
-
总则
- 坚持每个文件只定义一样东西（例如服务或者组件）
- 考虑把文件大小限制在 400 行代码以内
- 坚持定义简单函数来组装复杂函数
-
命名
- 使用点和横杠来风格文件名，不建议驼峰
- 坚持在描述性名字中，用横杠分割单词
- 坚持遵守先描述组件特性，再描述它的类型的模式，例如
feature.type.ts
调试
接下来介绍一下，如何借助 vscode(其它编辑器，cursor，trae 是同样的方式)，来调试 nest.js 和 hono.js 代码
首先我们简单介绍一下如何调试单文件 node.js 文件，这个对于我们 demo 也算比较有用。
首先，随便在跟目录建一个 index.js
然后我们在第 6 行，打了一个断点，可以看到红色标记。然后再根目录，建立一个 .vscode 文件夹，文件夹内建立一个 launch.json
接着点击 如下的 bug 按钮，就可以调试了
调试 nest
调试 nest 和 hono 都很相似，只是 launch.json 的配置不一样，
我们 launch.json 的配置如下（调试 nest 的）：
{
// 配置文件的版本号，遵循VSCode调试协议。0.2.0是当前常用版本。
"version": "0.2.0",
// 定义调试配置的数组，一个文件可以包含多个独立的调试配置。
"configurations": [
{
// 指定调试器类型。`node` 表示使用Node.js调试适配器，用于调试JavaScript/TypeScript。
"type": "node",
// 调试请求类型。`launch` 表示启动一个新程序进行调试；另一种是`attach`（附加到已运行进程， 这个不纠结，我们都用 launch）。
"request": "launch",
// 在VSCode调试下拉菜单中显示的名称，随便起个就行。
"name": "Launch Program",
// 指定实际用来运行程序的命令。这里使用`pnpm`包管理器作为启动器。
// 如果不设置此项，默认值为`node`。
"runtimeExecutable": "pnpm",
// 传递给`runtimeExecutable`（pnpm）的命令行参数。
// 等同于在终端执行：`pnpm run start:dev`
"runtimeArgs": ["run", "start:dev"],
// `runtimeVersion`主要用于通过`nvm`等版本管理器切换Node版本。
"runtimeVersion": "20.16.0",
// 调试时跳过（不进入）的文件。
// `<node_internals>/**` 表示跳过所有Node.js内置核心模块代码，使调试更聚焦于应用自身。
"skipFiles": [
"<node_internals>/**"
]
}
]
}
这里的关键是什么呢，就是 runtimeExecutable + runtimeArgs， runtimeExecutable 代表我们执行的命令使用 pnpm, 你可以改为 yarn， npm，都行，然后执行的命令参数runtimeArgs，合起来就是
pnpm run start:dev
为什么这样呢，因为 start:dev 是 nest.js 的 package.json 中注明的启动开发环境的命令,如下：
"scripts": {
"build": "nest build",
"format": "prettier --write \"src/**/*.ts\" \"test/**/*.ts\"",
"start": "nest start",
"start:dev": "nest start --watch",
"start:debug": "nest start --debug --watch",
"start:prod": "node dist/main",
"lint": "eslint \"{src,apps,libs,test}/**/*.ts\" --fix",
"test": "jest",
"test:watch": "jest --watch",
"test:cov": "jest --coverage",
"test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand",
"test:e2e": "jest --config ./test/jest-e2e.json"
},
当然，你可以用 start 命令，start:debug 命令都行，假设就用
// 指定实际用来运行程序的命令。这里使用`pnpm`包管理器作为启动器。
// 如果不设置此项，默认值为`node`。
"runtimeExecutable": "pnpm",
// 传递给`runtimeExecutable`（pnpm）的命令行参数。
// 等同于在终端执行：`pnpm run start:dev`
"runtimeArgs": ["run", "start:dev"],
然后我们在 app.controller.ts 上打个断点：
然后启动调试
点击后，相当于在命令行输入：
pnpm run start:dev
接着你浏览器访问 http://localhost:3000 就能触发断点了！
调试 hono
所以根据上面的理论，我们来创建一个 launch.json，用来调试 hono
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"runtimeExecutable": "pnpm", // 核心：告诉调试器用pnpm来运行
"runtimeArgs": ["run", "dev"], // 传给pnpm的参数：运行“dev”脚本
}
]
}
同理，其实就是触发了：
pnpm run dev
命令， dev 这个命令其实就是 hono 项目 package.json 中的内容：
"scripts": {
"dev": "tsx watch src/index.ts",
"build": "tsc",
"start": "node dist/index.js"
}
容器部署
接下来是很长的关于 docker 和我们前端全栈相关的知识，有深入的原理介绍，有兴趣的同学可以一起交流。
为什么需要 Docker？
即便是纯前端开发者，不涉及 Node.js、Nginx 或数据库等服务器相关软件，在中小企业部署应用时，后端团队或项目经理常常会要求前端团队提供一个 Dockerfile，以便将前端应用部署到 Nginx 上。这种要求在容器化时代变得越来越普遍。所以是有必要了解容器的知识的。
容器化的基本概念
在容器化时代，通常通过 Dockerfile（用于描述如何构建 Docker 容器的配置文件）构建开发或生产环境的 Docker 镜像，然后启动这些镜像，使外部网络可以访问对应的应用。
在 Docker 流行之前，前端应用的部署方式一般是直接在服务器上下载相关软件（如 Nginx、MySQL 或 PostgreSQL），配置并启动服务，再将打包后的前端内容放入 Nginx 的指定目录，以便外部访问。这种方式被称为物理机直接部署。
为何转向容器化部署？
容器化部署的优势主要体现在以下两个方面，我们用前端的视角去理解：
-
环境一致性：
- 前端常见的问题，为什么在 Chrome 中功能正常，但在其他浏览器中却无法运行？
-
简化环境配置：
- 前端项目通常需要配置 ESLint、Prettier、TSConfig、Vite/Webpack 等工具。这些配置繁琐，且需要一定的知识才能定制适合项目的配置。为了解决这些问题，前端社区提供了许多 CLI 工具，如 React 的 create-react-app、Vue 的 Vue CLI、Next.js 的 @nextjs/cli 等，这些工具为项目提供了现成的模板，并在 Babel/SWC 和 Browserslist 的配置中解决了兼容性问题。
同样，服务器端也面临环境一致性和配置繁琐的问题，并且这些问题相当棘手。为什么会这样呢？我们可以回顾一下 Docker 流行之前的 PaaS 项目。
PaaS 的背景
PaaS（Platform as a Service）是云计算的重要服务模型，旨在提供一个完整的应用开发、运行和管理环境，使开发者能够专注于编写代码，而无需担心底层基础设施或操作系统。
PaaS 受欢迎的原因
PaaS 项目受到广泛接纳的一个主要原因是它提供了“应用托管”能力。如今，许多人使用阿里云、腾讯云、AWS 等云服务，实际上就是将本地应用托管到云端。然而，这一部署过程常常会遇到云端虚拟机与本地环境不一致的问题。因此，当时的云计算服务竞争的焦点在于谁能更好地模拟本地服务器环境，从而提供更优质的“上云”体验。而开源 PaaS 项目的出现，正是为了有效解决这一问题。
docker 的出现
正当大家比谁能更好模拟本地服务器环境的时候，docker 跳出来说，对不起，在做的各位都是垃圾。。。我能完全模拟本地服务器环境，嘿嘿！
并且 docker 提供了非常便捷的打包机制， 并且这个压缩包包含了完整的操作系统文件和目录，也就是包含了这个应用运行所需要的所有依赖。只需：
docker build 打包自己的服务
docker run 启动自己的服务
如此，docker 轻松击败了 pass 本身的打包机制，后来逐渐使容器技术成为云服务的基础设施之一。
你可以想象，就跟前端使用 vite 和 webpack 一样，一键 npm run build xxx 打包后，你的前端应用能在各个浏览器上运行，并帮助我们解决了浏览器兼容性问题，如此便捷，谁能不喜欢这样的技术呢？
所以这个小节我们可以回答常见的面试题：
既然 docker 这么好用，那 docker 镜像，docker 容器，docker 镜像仓库等等常见概念是什么意思呢？我们拿前端的 npm 包管理来帮助我们理解。
Docker 必需了解的基础概念
1. Docker 镜像和 Docker 容器
镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的 类 和 实例 一样，镜像是静态的定义，容器是镜像运行时的实体。
-
Docker 镜像 是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。
-
Docker 容器的实质就是一个进程，但是跟普通进程不一样的是，因此容器可以拥有自己的
root 文件系统、自己的网络配置、自己的进程空间，甚至自己的用户 ID 空间。容器内的进程是运行在一个隔离的环境里，使用起来，就好像是在一个独立于宿主的系统下操作一样。
2. Dockerfile
dockerfile 是一个文本文件，包含了一系列指令，一般我们都是用这个文件配合 docker build 命令来构建 docker 镜像。
3. Docker Client、Docker hub、Docker Daemon
关系如下图：
上图中涉及 3 个重要的概念
- Docker Hub：Docker Hub 是一个云端托管的Docker镜像库，用户可以在其中存储和共享 docker 镜像。它类似于 npm 仓库。
- Docker Daemon：守护进程是一个后台服务，负责管理 docker 容器和镜像。它监听来自的 docker 客户端的命令，并执行相应操作。
- Docker Client：允许用户与守护进程交互的命令行工具。
【延伸补充】深入原理1：一定要理解 Docker 镜像的分层的原理
上面我们说了，Docker 镜像 是一个特殊的文件系统，其中有一个特别重要的特性，称之为文件系统分层。为了说明这个原理，我们需要从 linux 本身的文件系统讲起。
首先 linux 启动的时候，首先加载的是 bootfs 文件系统，它包含了 boot 加载器和 kernel 内核。kernel 内核作用是什么呢？我们知道计算机是由硬件构成的，例如 cpu、主板、外设、内存等等，最终这些硬件会被操作系统接手管理，例如，将在硬盘的程序映射为一个个动态的进程，然后增加 cpu 调度算法，让每个进程按照特定的规则不断运行，还需要管理内存，不断的读取内存指令给 cpu 运行。。。
然后 linux 会挂在 rootfs 文件系统，什么是 rootfs 呢？作用是什么呢？我们知道在玩 windows 操作系统的时候，C 盘一般都是用来存储操作系统相关的文件的，例如 C 盘下的 Program Files 一般用来存放操作系统相关的配置文件。
而 linux 中的 rootfs 在初始化的时候，也是把操作系统相关的文件放入其中。linux 有很多不同的发行版本，例如 centos，ubantu 等等，他们都有自己的 rootfs，规则有所不同。
而上面说的两个文件系统，在 docker 中，并不是混在一起的，而是如上图分层了的，这意味着，如果正在使用不同的 docker 镜像，他们最底层的 bootfs 很可能是一样的（相同的 linux 版本），那么这些镜像就可以共享这一层，而不是每个镜像都分别有一个 bootfs。
同理 rootfs 也是一样，如果我们使用的镜像都是基于 ubantu 的 linux 发行版本，版本号也是一样的话，那么 rootfs 也是可以共享的。
这样就会大大降低 docker 的体积，这也是为什么大家说 docker 轻量的原因。
docker 镜像本身提供的这些数据层是只读的，我们后续用 dockerfile 去自定义我们自己的镜像时，实在可读层上面加一个读写层，但是修改 docker 的，所以共享底层的数据层也不会影响我们定制化的 docker 镜像。
为什么理解分层如此重要呢？我们举个例子（以下 dockerfile 文件每个命令是什么意思会详细讲解，现在不用在意），以下 docker file 中，我们注意 RUN 命令：
FROM ubuntu:20.04
RUN apt-get update
RUN apt-get install -y python3
RUN apt-get install -y python3-pip
RUN apt-get clean
这里执行了 4 个 RUN 命令，而每个 RUN 命令都会单独在 docker 镜像上建立一个单独的读写层，这样会增大构建后的 docker 镜像体积，我们可以将其合并：
FROM ubuntu:20.04
RUN apt-get update && \
apt-get install -y python3 python3-pip && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
同样的，如果分层中，分层的内容没有变，docker 会重复利用这些已经打包好的层，什么意思呢？我们前端应用打包的时候，往往 package.json/package.lock.json 的依赖是没有变化的，所以我们如果能利用之前已经下载好的 npm 包的层，就不用重复下载了。
# 使用 Node.js 作为基础镜像
FROM node:22-slim
# 将 package.json 和 package-lock.json 复制到容器中
COPY package*.json ./
# 安装依赖（会在此层缓存 node_modules）
RUN npm install
# 复制应用程序的其他源代码到容器中
COPY . .
# 暴露应用程序运行的端口
EXPOSE 3000
# 启动应用程序
CMD ["npm", "start"]
以上我们会看到 RUN npm install 这一步，如果命令跟以前一样，会利用缓存，不会下载 npm 包，具体缓存规则，官方叙述如下（建议后续看完 dockerfile 章节后再回来看这部分，非常重要）：
在镜像的构建过程中，Docker 会遍历 Dockerfile 文件中的指令，然后按顺序执行。在执行每条指令之前，Docker 都会在缓存中查找是否已经存在可重用的镜像，如果有就使用现存的镜像，不再重复创建。如果你不想在构建过程中使用缓存，你可以在 docker build 命令中使用 --no-cache=true 选项。 但是，如果你想在构建的过程中使用缓存，你得明白什么时候会，什么时候不会找到匹配的镜像，遵循的基本规则如下：
- 从一个基础镜像开始（
FROM 指令指定），下一条指令将和该基础镜像的所有子镜像进行匹配，检查这些子镜像被创建时使用的指令是否和被检查的指令完全一样。如果不是，则缓存失效。
- 在大多数情况下，只需要简单地对比
Dockerfile 中的指令和子镜像。然而，有些指令需要更多的检查和解释。
- 对于
ADD 和 COPY 指令，镜像中对应文件的内容也会被检查，每个文件都会计算出一个校验和。文件的最后修改时间和最后访问时间不会纳入校验。在缓存的查找过程中，会将这些校验和和已存在镜像中的文件校验和进行对比。如果文件有任何改变，比如内容和元数据，则缓存失效。
- 除了
ADD 和 COPY 指令，缓存匹配过程不会查看临时容器中的文件来决定缓存是否匹配。例如，当执行完 RUN apt-get -y update 指令后，容器中一些文件被更新，但 Docker 不会检查这些文件。这种情况下，只有指令字符串本身被用来匹配缓存。
一旦缓存失效，所有后续的 Dockerfile 指令都将产生新的镜像，缓存不会被使用。
【延伸补充】深入原理2：一定要理解什么是构建上下文
上面有一个很容易混淆的路径问题，COPY package*.json ./ 中 package*.json 指的并不是 docker build 命令的目录，也不是 Dockerfile 所在的目录，而是执行上下文的目录。执行上下文目录我们是在 docker build 的时候指定的，这里我们指定的 .，表示执行 docker build 命令时的目录。
为什么这个概念如此重要，很有可能你你设置的不对，根本找不到 package*.json，例如你这样
COPY ../package*.json ./
../package*.json，指的是构建上下文上一层目录的 package*.json，其实是找不到的，因为我们将构建上下文复制到 docker host 的时候，docker 只会复制构建上下文内的内容（并且除开 .dockerignore file 指定的排除的内容）。
所以你在构建上下文之外找 package*.json，肯定是找不到的。
并且有相当多网上的人误以为 . 是指定 Dockerfile 所在目录呢？这是因为在默认情况下，如果不额外指定 Dockerfile 的话，会将上下文目录下的名为 Dockerfile 的文件作为 Dockerfile。
这只是默认行为，实际上 Dockerfile 的文件名并不要求必须为 Dockerfile，而且并不要求必须位于上下文目录中，比如可以用 -f ../Dockerfile.php 参数指定某个文件作为 Dockerfile。
当然，一般大家习惯性的会使用默认的文件名 Dockerfile，以及会将其置于镜像构建上下文目录中。
最后最最重要的就是需要写一份 .dockerignore 文件，例如，我们前端项目往往都有 node_modules 目录，而且体积相当大，所以没必要将其复制到 docker host。
- 这会显著增加镜像的体积，从而影响镜像构建时间和传输效率。
-
node_modules 中的某些依赖可能是平台相关的（例如，使用了原生代码或编译步骤），在不同的操作系统（如 Windows 和 Linux）上会有所不同。
好了，我们接着编写完 dockerfile 文件继续说。
然后，就可以运行 docker 镜像
docker run -d -p 3000:80 react-app
-
-d：以后台模式运行容器。
-
-p 3000:80：将本地的 8080 端口映射到容器的 80 端口。
然后本地访问 localhost: 3000，或者你的机器有外网地址，使用 <外网地址>: 3000，访问即可。
这里还会牵扯到一个需要深入讨论的内容，就是容器网络的原理，我们后续再谈。
这里我们总结一下一些常用的 docker 命令，帮助大家快速用起来 docker。
常用命令总结
下载镜像：docker pull <镜像名>，例如下载 node.js 22 版本的镜像
docker pull node:22-slim
注：可以用 docker hub 来搜索支持的版本。方法如下：
列出镜像：
docker images
删除镜像：docker rmi -f <镜像名>，例如：
docker rmi -f nginx
新建并启动容器：docker run -d -p <本地端口>:<容器端口> <镜像名>，例如
docker run -d -p 80:80 --name nginx nginx:1.17.0
列出容器：
docker ps
查看运行中的容器：
docker ps
如果加入 -a 参数，即使暂停的容器也会被列出来。
停止容器：
docker stop <容器ID | 容器名字>
删除容器：
docker rm <容器ID | 容器名字>
在宿主机查看docker使用cpu、内存、网络、io情况：
docker stats <容器ID | 容器名字>
进入Docker容器内部的bash
docker exec -it <容器名字> /bin/bash
注意，有的镜像里面没有 bash 命令，例如 nginx，可以将 /bin/bash 改为 /bin/sh
以上的知识，足够前端应付常见的场景了，遇到问题搜索一下，看懂也不是难事。其实容器的网络，是比较特殊的，因为容器实际上看起来是有自己独立的文件系统，独立的网络，独立的进程的（也就是在容器中，你会看懂容器进程的 id 是 1）等等。
既然有自己独立的网络，那么容器的网络如何跟外界打通，原理又是什么呢？（这个问题特别重要，无论对于你自己本地调试，还是生产环境解决容器无法访问的问题）
既然有自己独立的文件系统，那么容器销毁，容器里面的文件也随之销毁，那么容器如何做到将文件跟物理机上的文件系统共享的呢？
【延伸补充】深入原理3：docker 容器的底层三大核心技术
三大核心技术分别是 namespace、Cgroup 以及联合文件系统，联合文件系统上面已经讲了，现在就剩下 namespace 和 Cgroup 了。我们先来看看 pid namespace 是什么。
首先再次强调，容器就是一个进程。举个例子
我们首先使用以下命令来获取到容器的进程 id 为 2526
docker inspect <容器 id> | grep Pid
然后使用 ps 命令来过滤出 2526 进程
ps -ef | grep 2526
发现确实有对应的进程。
但是跟普通进程不一样的是，容器的进程利用 namespace 技术，让我们进入容器后，发现容器主进程的 pid 是 1 ，而不是 2526。也就是容器使用了"障眼法"，来让自己跟别的容器都隔离开。就拿进程隔离来说，容器是如何修改进程视图的呢？如下图：
如上图，1、2、3、4、5、6、7、8、9、10，都是在物理机操作系统上的进程号（PID），而进入容器后，PID 8 是容器的主进程，linux 将其修改为进程号（PID）为 1，子进程也同样修改 PID，这样你在容器里，看到主进程是 PID 1，但是你退出容器，查看这个容器的进程号，就是 8。
namespace 不仅仅隔离了进程的 pid，还包括网络、用户、IPC 等等。接着我们看看 Cgroup 是什么。
你想想，虽然视图可以改变，但是却没法限制这个容器对 cpu 的使用，所以是有可能单个容器把 cpu 跑满的。所以如果能限制 cpu、内存的使用就更好了，Cgroup 就是做这个事的。
Cgroup 的原理如下图：
Cgroup 对不同资源进行了分组，例如 cpu 总共是 100%，假设分配给某个容器是 25%，当你进入容器中，你看到的自己 cpu 总共是 100% ，也就是这个容器里的 100% 是假的，其实是从真实的 25% 里面去分的。
Cgroup 如何操作是有对应的 linux 命令的，这里我们就不深入了，因为性价比并不高，用好 docker 就可以了。
【延伸补充】深入原理4：docker 容器网络的秘密
为了更通俗的解释 docker 的桥接网络，我们先从计算机网络基本的知识讲起：
如下图，只需要一根网线相互连接，然后在计算机上配置一下自己的 ip 地址（在一个网段里），两台计算机就可以相互通信了。例如 A 计算机的 ip 我们写死 ip 到网卡，地址为 192.168.1.1/24，B 计算机是 192.168.1.2/24 ，他们都是 192.168.1.xxx 网段。
有些同学可能不理解，为啥要分配 ip 地址？因为我们很多通信协议是基于 ip 协议的，例如 http，tcp。所以必须分配 ip 地址，才能让数据包走出网卡。我们接着聊:
现在我们多加一些电脑，这时候一根网线肯定就不够了，我们就加入一个交换机（虚拟交换机是有 ip 的，但是现实生活中的交换机是没有 ip），如下图
假设交换机的 ip 是 192.168.1.1/24，这个交换机还可以自动分配 ip（dhcp协议），只要计算机连接交换机，就会自动分配一个不重复的 ip 地址，那么多台计算机互相通信就解决了。
其实 docker 内部默认有一个叫做 docker0 的网桥，这个网桥工作机制就跟我们上面说的交换机类似。而容器默认情况下，会连接 docker 0 网桥。如下图：
这样容器之间互通的问题我们就解决了。
那么如何解决容器跟外部网络通信的问题，例如某个容器去访问微信登录。
如下图，其实 docker0 是连接到我们真实物理机的网卡 eth0 来转发数据，从而让容器的数据通过 -> docker0 -> eth0 发送到计算机外部
这里又有问题了，容器内部的 ip 往往是一个内部地址，什么是内部地址？你会看到，我们前端启动前端应用，经常看到启动的 ip 地址是 192.168.x.x，你回到家启动前端应用分配的地址居然是一样的 192.168.x.x。我们知道 ip 地址必须全网唯一，为啥在家里分配的 ip 和在公司分配的 ip 一样呢？
这是因为 ip 地址规定了一些只能在内网通讯的地址，不能用在外网，例如 192.168.x.x 就是不会用在外部网络访问的 ip 地址。
这对于 docker 容器访问外部网络就有问题了，你想想 docker容器 -> docker0 -> eth0 将数据包传给了微信服务器，微信服务不能说我回传的 ip 地址是 docker容器的 ip，因为 docker容器的 ip 是内部地址，不能在网络上传输。
这里又涉及一个概念，叫 nat 转换，也就是 docker 容器将数据包传给 eth0 的时候，会改写自己数据包发送端的 ip 地址为 eth0 的公网地址。
这样就解决了容器访问外部网络的问题了。
问题又来了哦，那返回给 eth0 的数据，如何知道这个数据包最终转发给哪个容器呢？这里涉及到一个叫做 iptables 的工具（NAT 转换也是依赖它），它可以记录转发规则，例如如果这个数据是从 80 端口出去的，那么返回的时候，就返回给 A 容对应的内部 ip。
【延伸补充】深入原理5：docker 容器文件隔离和共享的秘密
文件隔离
docker 容器的文件系统是跟宿主机隔离的，在 docker 里，我们能看到一份独立的文件系统。linux 如何实现的呢？
实际上 linux 也是用了障眼法做到的，如下图，首先假设下图是正常的某台 linux 机器的目录结构：
然后我们希望 docker 容器跟 joe 目录（最右边最后一个目录）拿来作为容器的根目录，使用 linux 的 Mount Namespac 功能 + chroot 命令，结果如下图：
容器的根目录，挂载到了宿主机的 joe 目录。由于 Mount Namespace 技术的特性，这个容器的根目录对于宿主机是看不见的。
而这在某些情况下不是我们想要的。比如数据库文件，我们想留在宿主机上，这样重启容器的时候，依然保留了数据库的数据。
而这里要使用到的挂载技术，就是Linux的绑定挂载（bind mount）机制。它的主要作用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。并且，这时你在该挂载点上进行的任何操作，只是发生在被挂载的目录或者文件上，而原挂载点的内容则会被隐藏起来且不受影响。
文件共享
由于容器的特性，如果容器删除，那么容器里的数据也会删除，之前的挂载功能也会解除。可是在某些情况下，我们希望保留容器里的数据，例如数据库，方便再下一次启动镜像的时候能共享之前容器的数据。
这个功能在 docker 叫做绑定 Volume 功能。 这个功能的实现其实很简单，之间我们讲的绑定挂载，其实需要分为两步，第一步开启 Mount Namespace，此时容器内部仍然可以看到宿主机的目录，但是宿主机看不到容器的目录，第二步执行类似 chroot 命令，可以简单理解为执行后，容器就看不到宿主机目录了。
所以我们可以在第一步之前，把 Volume 指定的宿主机目录（比如/home目录），挂载到指定的容器目录（比如/test目录）在宿主机上对应的目录上，这个 Volume 的挂载工作就完成了。
最后补充
补充，之前前端部署的 dockerfile 一般都会用分阶段构建的方法，首先借助 node.js 镜像打包前端应用，然后将打包好的内容放入 nginx 镜像中，最后借助 nginx 作为 web 服务器，来让外网访问。我们简单实现一下，可用在生产环境：
# Use the official Node.js runtime as the base image
FROM node:20-slim as build
# Set the working directory in the container
WORKDIR /app
# Copy package.json and package-lock.json to the working directory
COPY package*.json ./
# Install dependencies
RUN npm install
# Copy the entire application code to the container
COPY . .
# Build the React app for production
RUN npm run build
# Use Nginx as the production server
FROM nginx:alpine
# Copy the built React app to Nginx's web server directory
COPY --from=build /app/build /usr/share/nginx/html
# Expose port 80 for the Nginx server
EXPOSE 80
# Start Nginx when the container runs
CMD ["nginx", "-g", "daemon off;"]
需要注意的是
COPY --from=build /app/build /usr/share/nginx/html
--from build , 这个 build 就是 FROM node:20-slim as build 中，node.js 镜像的别名。意思是把这个镜像中 /app/build 目录下的文件复制到 nginx:alpine 镜像的 /usr/share/nginx/html 文件夹下。
欢迎加入交流群
欢迎大家一起进群讨论前端全栈技术和 ai agent ，一起进步！
登录
