企业官网建设流程全解析

📚前言

📒FDE系列内容总纲：

【大纲】FDE 前沿部署工程师学习系列教程-CSDN博客

🚄前置课程列表：

见文档结尾附录。

🚀阶段2·Day 44：Nginx 反向代理 + Git 版本控制

FDE 学习系列教程 · 第二阶段 · 第 5 周 · Day 4预计时长：3 小时 | 难度：★★★☆☆ | 前置知识：Day 41-43 Docker/Compose、Linux 基础

📌一句话目标：配置 Nginx 反向代理让标准 80 端口转发到 FastAPI，理解负载均衡原理；掌握 Git 的提交、分支、回滚、远程推送全流程，让代码有历史、可协作。

🧑‍🤝‍🧑 开场：今天补齐两块"标配拼图"

到昨天为止，你的服务已经能docker compose up一键跑起来了。但还剩两个绕不开的现实问题：

问题一：用户记不住 8000 端口。你的 API 跑在 8000，数据库在 3306，phpMyAdmin 在 8080。用户在浏览器敲http://服务器地址:8000？既不专业，也不安全。正常网站都是直接http://域名（走 80 端口），没人带端口号。中间需要一个"前台接待"把 80 端口的请求转进内部服务——这就是Nginx 反向代理。

问题二：代码还在裸跑。你现在改代码靠什么？改坏了想退回昨天的版本怎么办？多人一起开发怎么合并？用文件夹复制出项目_备份1、项目_最终版、项目_最终版_真的最终？这就是Git要解决的。

上午 Nginx，下午 Git，都是 FDE 每天打交道的基础设施，走起。

第一部分：Nginx 反向代理

📖 一、正向代理 vs 反向代理

两个名字都带"代理"，但代理的对象完全相反。先分清这个，配置就好理解了。

Nginx 当反向代理能干啥

两种安装方式

在WSL 和这容器里安装，主要是载体的区别，WSL 和容器（Docker）是两个层面、目标不同但常配合使用的技术。：

Windows 上的Docker Desktop 默认用 WSL2 作为后端：它在 WSL2 里跑一个专用发行版docker-desktop来承载 Docker Engine，你在 Windows 的 PowerShell 或 WSL 终端里都能用docker命令，容器实际跑在 WSL2 内核上。

🖥️ 二、方式一：直接在 WSL 安装 Nginx

先体验最朴素的安装方式（和客户传统服务器一致）,打开你的 WSL 终端，依次执行：

sudo apt update sudo apt install -y nginx # 验证 nginx -v # nginx version: nginx/1.18.0 (Ubuntu) # Nginx 安装后通常自动启动了 curl http://localhost # 看到 <!DOCTYPE html>... Welcome to nginx! 说明 80 端口已在服务

配置文件结构（Ubuntu/Debian 系）

/etc/nginx/ ├── nginx.conf # 主配置文件（全局设置） ├── sites-available/ # 可用的站点配置（写在这里） │ └── fde-api # ← 我们要建的 └── sites-enabled/ # 已启用的站点（放软链接到这里才生效） └── fde-api -> ../sites-available/fde-api

这种"available + enabled"的两段式设计很经典：配置写在 available，想启用就在 enabled 里建个软链接（快捷方式），想下线删软链接即可，配置文件本身不删。

写反向代理配置

# 以 root 权限，用 nano 编辑器打开（或新建）一个名为 fde-api 的 Nginx 站点配置文件 sudo nano /etc/nginx/sites-available/fde-api

写入：

server { listen 80; # Nginx 监听 80 端口 server_name localhost; # 域名/IP；本地练习用 localhost # 所有请求（/）都转发给 FastAPI location / { proxy_pass http://127.0.0.1:8000; # ⭐ 核心：转发目标 proxy_set_header Host $host; # 把原始域名带给后端 proxy_set_header X-Real-IP $remote_addr; # 真实客户端IP proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 原始协议 http/https } }

启用 + 生效：

# ① 建软链接启用站点 sudo ln -s /etc/nginx/sites-available/fde-api /etc/nginx/sites-enabled/ # ② 删掉默认站点（它也占 80 端口，会冲突） sudo rm /etc/nginx/sites-enabled/default # ③ 测试配置语法（改配置后必做！） sudo nginx -t # nginx: configuration file /etc/nginx/nginx.conf test is successful # ④ 重载配置（不断连接的平滑生效，改完配置用 reload 而非 restart） sudo systemctl reload nginx

确保 FastAPI 在 8000 跑着（用第 4 周学的 nohup，或 docker 跑昨天的 api），然后验证：

# 直接访问 80（不带端口），Nginx 转给 8000 的 FastAPI curl http://localhost/ # {"msg":"FDE Stack",...} curl http://localhost/health # {"status":"ok","db":"connected"}

proxy_pass 与请求头逐项解释

用户请求 Nginx :80 FastAPI :8000 http://localhost/ ─────────────proxy_pass─────────────► │ ├─ Host: $host │ 告诉后端"用户原本访问的域名" │ 后端生成跳转链接时要用 │ ├─ X-Real-IP: $remote_addr │ 后端日志里记录的不再是 Nginx 的 IP， │ 而是真实用户 IP（审计、限流要用） │ └─ X-Forwarded-For / -Proto 经过的代理链、原始协议

💡 为什么要传这些头？经过反向代理后，FastAPI 直接看到的"来访者"是 Nginx（127.0.0.1），不是真实用户。这些X-开头的请求头负责把"原始信息"一路带进去，行业标准做法，照抄即可。

🖥️ 三、方式二：用容器跑 Nginx（和 Compose 一体化，推荐）

既然整个技术栈都容器化了，Nginx 也应该进 Compose，而不是装在宿主机上。这样整套环境还是"一条 up 全起来"。

在昨天fde_stack的docker-compose.yml里加第三个服务：

# ---------- 服务 3：Nginx 反向代理 ---------- nginx: image: nginx:alpine container_name: fde-nginx ports: - "80:80" # 对外只暴露 80 volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf # 挂载配置文件 depends_on: - api restart: unless-stopped

新建nginx.conf（注意：容器版的转发地址写服务名 api，不是 127.0.0.1）：

# 定义后端服务器组（负载均衡在这里配） upstream fde_backend { server api:8000; # api 是 Compose 服务名，内部 DNS 解析 } server { listen 80; server_name localhost; location / { proxy_pass http://fde_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

⚠️两种部署方式的转发地址区别（极易错）：

• Nginx 装在宿主机、FastAPI 也在宿主机：proxy_pass http://127.0.0.1:8000

• Nginx 在容器里、FastAPI 在另一个容器：proxy_pass http://api:8000（用服务名，走 Compose 内部网络）

此时 api 服务不需要再把 8000 映射到宿主机（可以删掉它的ports），让它只通过内部网络供 Nginx 访问——更安全，外部无法绕过 Nginx 直连 API。

启动并验证：

docker compose up -d curl http://localhost/ # 走 80 → Nginx → api:8000 # {"msg":"FDE Stack",...}

完整架构图

用户浏览器 │ http://服务器地址（80端口） ▼ ┌──────────────────┐ │ Nginx 容器 :80 │ ← 唯一对外暴露的入口 │ 反向代理 │ └────────┬─────────┘ │ proxy_pass（内部网络，服务名 api） ┌────────▼─────────┐ ┌────────────────┐ │ FastAPI :8000 │ ───► │ MySQL :3306 │ │ （不对外暴露） │ │ （内部网络） │ └──────────────────┘ └────────────────┘ 对外只开一个 80 端口；api/db 都藏在内部网络

📖 四、负载均衡：了解原理（高频面试点）

upstream块的真正威力是后端有多台服务器时分发请求。假设你部署了 3 个 API 实例：

upstream fde_backend { # 默认轮询：请求 1→api1，2→api2，3→api3，循环 server api1:8000 weight=3; # weight 权重：分到的概率是别人的3倍 server api2:8000 weight=1; server api3:8000 backup; # backup 备用：前两台全挂了才启用 }

Nginx ┌───────┼───────┐ ▼ ▼ ▼ api1 api2 api3 (权重3) (权重1) (备用) 常见调度策略： · 轮询（默认） 一个接一个均匀分发 · weight 加权轮询 性能强的机器多分点 · ip_hash 同一用户IP固定打到同一台（会话保持） · least_conn 分给当前连接数最少的

这块先理解原理，小项目单实例用不上。但 FDE 遇到客户高并发、或要做"灰度发布/多实例"时，就是这套配置。

💡 Nginx 改配置的标准三步，养成肌肉记忆：改配置 →nginx -t测语法 → reload 平滑生效。永远不要不测试就 reload，一个语法错误可能让整个站点挂掉。

第二部分：Git 版本控制

📖 五、Git 解决什么问题

先看没有 Git 的世界：

工单系统_最终版.doc 工单系统_最终版2.doc 工单系统_最终版_真的最终.doc 工单系统_最终版_真的最终_改.doc 工单系统_最终版_真的最终_改_给客户.doc ……

代码同理。这种"复制改名"式版本管理有三个死穴：

1. 看不出差异：两个"最终版"到底改了哪几行？

2. 回不去：今天改坏了，想退到上周能跑的版本？难

3. 合不了：你和同事同时改 main.py，谁覆盖谁？

Git 是分布式版本控制系统：每次提交都是一个带说明的"存档点"，记录了那一刻所有文件的快照。你可以随时查看历史、对比差异、退回任意版本、开分支并行开发。

提交（commit）就像游戏存档： ●────●────●────● 时间线 初始 加登录 修bug 加工单 ▲ ▲ └─ 任何时候都能读档回到这个点

🖥️ 六、Git 基础操作全流程

git简介

Git 是一个分布式版本控制系统，由 Linus Torvalds 于 2005 年为管理 Linux 内核开发而创建。它的核心作用是记录代码/文件的历史变化，支持多人协作，并能随时回退到任意历史版本。

核心特点

• 分布式：每个克隆都是完整仓库，含全部历史，可离线提交、查看历史，不依赖中央服务器。

• 快照式存储：每次提交保存项目完整快照（通过内容寻址去重，存储上并不浪费），而非逐版本存差异。

• 内容寻址：所有数据以 SHA-1/SHA-256 哈希为键存入对象库，内容不可变，天然防篡改。

• 轻量分支：分支只是一个指向提交的指针文件，创建/切换极快，鼓励频繁分支。

• 完整性校验：任何数据损坏或篡改都会导致哈希不匹配，易于发现。

• 强大的合并能力：支持三方合并、变基、cherry-pick 等，能处理复杂的并行开发。

基本工作模型

三个区域：工作区、暂存区、仓库。提交历史构成有向无环图（DAG），合并提交有多个父节点。

git原理

Git 仓库的本质是一个键值存储（key-value store）。所有数据都以对象的形式保存在.git/objects目录下，每个对象用其内容的 SHA-1（或 SHA-256）哈希值作为唯一键。

四种对象类型

关键点：

• blob 不含文件名。文件名和权限存在 tree 对象里。同样内容的不同文件只存一份 blob，天然去重。

• tree 可以指向 blob 或其他 tree，形成目录树。

• commit 指向一棵 tree（该提交的完整快照根目录）和零到多个父 commit。

• 每个对象的内容一旦写入就不可变，哈希值由内容决定。改一个字节，哈希全变。

对象如何存储

对象先经 zlib 压缩，再以objects/xx/yyyy...的松散对象形式存放（前两位做目录）。对象多了之后会打包成packfile（.git/objects/pack/*.pack+.idx），使用 delta 压缩存储相似对象，节省空间并加速传输。

哈希计算

Git 对对象做哈希时，会在内容前加一个头："<类型> <字节数>\0"，再对整体求 SHA-1。所以blob、tree、commit的哈希空间互不冲突。

安装

安装 Git 的方法取决于你使用的操作系统。安装完成后，通常还需要配置一下用户名和邮箱，才能开始提交代码。

Windows 系统

最推荐的方式是从官网下载安装包，或者使用包管理器。

方式一：安装包（推荐）

1. 访问 Git 官网下载页面 (git-scm.com/install/windows)，下载最新的 64 位安装程序。
2. 双击运行安装包。安装过程中有多个选项，对于大多数用户，保持默认选项一路“Next”即可。
3. 关键一步：在“Adjusting your PATH environment”界面，建议选择中间的“Git from the command line and also from 3rd-party software”。这样你才能在 CMD 或 PowerShell 中直接使用git命令。
4. 安装完成后，你可以在桌面或文件夹空白处右键，选择 “Git Bash Here” 来打开 Git 终端。

方式二：命令行（WinGet）
如果你习惯用命令行，可以在 PowerShell 或 CMD 中运行以下命令：

winget install --id Git.Git -e --source winget

macOS 系统

macOS 上最简便的方法是使用 Xcode 命令行工具或 Homebrew。

方式一：Xcode 命令行工具（最简单）
打开“终端”，直接输入git --version。如果系统检测到未安装，会自动弹窗提示你安装“命令行开发者工具”，点击安装即可。

方式二：Homebrew
如果你已经安装了 Homebrew，运行以下命令即可安装最新版：

brew install git

Linux 系统

直接使用你所用发行版的包管理器安装即可。

• Debian / Ubuntu：sudo apt install git
• Fedora：sudo dnf install git
• Arch Linux：sudo pacman -S git
• openSUSE：sudo zypper install git

Git 通常已经随系统或开发工具装好。先确认：

git --version # git version 2.34.x

第 1 步：一次性配置身份（只做一次）

git config --global user.name "你的名字" git config --global user.email "你的邮箱@example.com" # 可选：让默认分支名叫 main（新版惯例） git config --global init.defaultBranch main # 查看配置 git config --list

第 2 步：初始化仓库

cd ~/docker_lab/fde_stack # 进入你的项目目录 git init # Initialized empty Git repository in /home/fde/docker_lab/fde_stack/.git/

这会建一个隐藏的.git/目录——Git 的全部历史和数据都存在这里面，别动它。

第 3 步：写 .gitignore（和 .dockerignore 同样重要）

新建.gitignore，告诉 Git 哪些文件不纳入版本管理：

# Python __pycache__/ *.pyc venv/ .venv/ # 环境变量（密码！绝不提交） .env # 日志 *.log # 操作系统/IDE .DS_Store .vscode/ .idea/ # 数据库数据卷（如果在本地目录） mysql_data/

📌.env、密钥、venv、数据卷这些必须忽略：密码进了 Git 历史（尤其是推到 GitHub 公开仓库）等于公开泄露；venv 几百 MB 也不该进版本库（别人用 requirements.txt 自己装）。

第 4 步：查看状态、暂存、提交

# ① 看状态：哪些文件新增/修改/被忽略（最高频命令，随时敲） git status # ② 暂存（add）：把改动放进"购物车" git add . # 暂存所有改动 git add docker-compose.yml # 或只暂存指定文件 # ③ 提交（commit）：把购物车的东西结账，生成一个存档点 git commit -m "feat: 初始化 FastAPI+MySQL+Nginx 技术栈" # -m 后面是提交信息，说清楚这次干了啥

Git 的三个工作区（核心模型）

为什么要多一个"暂存区"？让你能挑选改动分批提交：比如你一次改了 3 个文件，其中 2 个是新功能、1 个是修 bug，可以分两次 add + commit，历史更清晰。

第 5 步：查看历史与差异

# 看提交历史 git log git log --oneline # 简洁版：每个提交一行（最常用） # a1b2c3d feat: 初始化 FastAPI+MySQL+Nginx 技术栈 # d4e5f6g docs: 添加 README git log --oneline --graph # 图形化显示分支 # 看【还没暂存】的改动内容（工作区 vs 暂存区） git diff # 看【已暂存】将被提交的内容 git diff --staged

🖥️ 七、分支：平行宇宙式开发

分支让你能在不影响主线的情况下开发新功能，这是 Git 的灵魂。

main（主线，始终保持可用） ●───────────●───────────●──────── \ ╱ ●──────●──────●────╱ feature/user-api（功能分支：在这折腾，坏了不影响 main）

# 查看分支（* 表示当前所在分支） git branch # * main # 创建并切换到新分支 git checkout -b feature/user-api # 等价于：git branch feature/user-api + git checkout feature/user-api # 新版也可以用：git switch -c feature/user-api git branch # * feature/user-api # main # ……在分支上改代码、提交…… git add main.py git commit -m "feat: 添加用户查询接口" # 切回主线（工作区文件会变回 main 的样子） git checkout main # 把功能分支合并进 main git merge feature/user-api # 合并后删除功能分支（已合并且不再需要） git branch -d feature/user-api

常见分支约定（了解即可）：

💡 FDE 个人项目最小工作流：main保持可用 → 每个新功能开feature/xxx→ 做完测好合并回main→ 删分支。简单有效。

🖥️ 八、远程仓库：GitHub/GitLab 协作与备份

本地历史再全，硬盘坏了也白搭。远程仓库既是云端备份，又是多人协作中心。

推送你的项目到 GitHub

1. 注册 GitHub 账号（https://github.com），建议装好 SSH key 或用凭据管理器

2. 在 GitHub 网页点New repository，名字如fde-stack，不要勾选初始化 README（本地已有内容）

3. 关联远程并推送：

# 给本地仓库添加远程地址，惯例命名为 origin git remote add origin https://github.com/你的用户名/fde-stack.git # 第一次推送：-u 把本地 main 和远程 main 关联，以后直接 git push git push -u origin main # 以后提交完推送 git push

协作三件套

# 把远程最新改动拉下来并合并（开工前先 pull，避免冲突） git pull # 把别人的仓库完整克隆到本地（含全部历史） git clone https://github.com/某人/某项目.git # 查看远程地址 git remote -v

典型协作循环： ① git pull 先拉最新（拿到同事的提交） ② 改代码 ③ git add / commit 本地存档 ④ git push 推上去 如果 push 被拒（远程有新提交）→ 先 pull 合并 → 再 push

冲突（conflict）怎么处理

你和同事改了同一文件的同一行，Git 无法自动决定听谁的，就会报冲突：

Auto-merging main.py CONFLICT (content): Merge conflict in main.py

打开冲突文件，会看到冲突标记：

<<<<<<< HEAD return {"msg": "我的版本"} ← 当前分支的内容 ======= return {"msg": "同事的版本"} ← 要合并进来的内容 >>>>>>> feature/xxx

手动编辑：删掉<<<<<<<、=======、>>>>>>>标记，保留你想要的最终内容，然后：

git add main.py git commit # 保存合并结果（Git 会自动生成合并提交信息）

📖 九、后悔药：常见撤销操作

revert vs reset 的区别（重要）： 历史：A ── B ── C（C 是有问题的提交） git revert C： A ── B ── C ── C'（C' 是"撤销C所做改动"的新提交） 历史完整保留，安全，适合已 push 的提交 ⭐ git reset --hard B： A ── B（C 直接从历史抹掉） 改写历史，只适合【没 push】的本地提交

⚠️红线：已经 push 到共享分支的提交，不要用reset --hard+ 强制推送（git push -f），会把同事的提交搞丢。共享分支用revert。

📝 本课小结

Nginx 部分

Git 部分

🧠 核心认知：

1. Nginx 是系统的统一门面：对外只暴露 80/443，内部服务藏在后面，转发、负载、SSL、安全都在这一层处理。

2. Git 是代码的时间机器 + 协作底座：小步提交、分支隔离、远程备份，是每个工程师的基本功。FDE 写的 Dockerfile、compose、脚本都应该进 Git。

📋 课后练习

练习 1：Nginx 反向代理（约 25 分钟）

1. 在 Compose 栈中加入 nginx 服务和 nginx.conf，up -d启动

2. 用curl http://localhost/（不带端口）访问到 API

3. 故意把 proxy_pass 改成错误地址，nginx -t还能通过吗？reload 后访问现象是什么？改回来

4. 尝试删掉 api 服务的ports: 8000:8000，验证通过 Nginx 仍能访问，但直接访问 localhost:8000 不通了

练习 2：Git 本地全流程（约 30 分钟）

1. 给 fde_stack 项目git init，写好 .gitignore，完成首次提交

2. 用git log --oneline查看

3. 创建feature/device-api分支，给 main.py 加一个/devices/hot（返回温度>80的设备）接口，提交

4. 切回 main，确认新接口"消失"了；再 merge 分支，确认它"回来"了

5. 删除功能分支

练习 3：推送到 GitHub（约 20 分钟）

1. 在 GitHub 新建仓库，git remote add origin关联并push -u origin main

2. 在网页上确认文件都上去了，并确认.env、venv没有被提交

3. 小实验：删掉本地某个文件 →git status看到删除 →git checkout -- 文件名恢复

🔭 下节预告

Docker、Compose、Nginx、Git 四样东西今天各自学了。明天是本周收官，来一次完整的端到端实战，把它们串成一条真实交付流水线：

Git 拉代码 → 配置环境变量 → Compose 构建 → 一键启动 API+MySQL+Nginx → curl 全链路验证 → 改代码后重新部署。

你会得到一个可以放进作品集的完整项目结构，并用一张大图把第 5 周知识全部串起来。明天见！

🌍附录：前置课程列表

阶段一：认知启蒙（AI 认知与 FDE 角色）

AI 认知

【FDE系列】阶段1Day 1：AI 层级关系 — 四个嵌套的圈-CSDN博客

【FDE系列】阶段1Day 2：AI 三阶段发展史 — 会认 → 会判断 → 会创造-CSDN博客

【FDE系列】阶段1Day 3：符号 AI vs 机器学习 — 两条路线的本质区别-CSDN博客

【FDE系列】阶段1Day 4：Transformer 的历史意义 — 2017 年的分水岭-CSDN博客

【FDE系列】阶段1Day 5：本周复习与自测 — 检验你的 AI 认知地基-CSDN博客

【FDE系列】阶段1Day 6：Transformer 架构 — 一张图纸盖出千千万万栋楼-CSDN博客

【FDE系列】阶段1Day 7：LLM 本质 — 文字接龙机器-CSDN博客

【FDE系列】阶段1Day 8：Token — 模型眼中的最小单位-CSDN博客

【FDE系列】阶段1Day 9：AI 幻觉 — 为什么会一本正经地胡说八道-CSDN博客

【FDE系列】阶段1Day 10：上下文窗口 — 模型的记忆力上限 + 本周复习-CSDN博客

【FDE系列】阶段1Day 11：Prompt — 给模型立规矩-CSDN博客

【FDE系列】阶段1Day 12：Memory — 让模型记住上下文

【FDE系列】阶段1Day 13：RAG — 给模型配图书管理员-CSDN博客

【FDE系列】阶段1Day 14：Tool Use — 让模型动手操作-CSDN博客

【FDE系列】阶段1Day 15：MCP — 统一的工具接口标准 + 第三周复习-CSDN博客

FDE 基础概念

【FDE系列】阶段1Day 16：什么是 FDE — 把 AI 变成客户结果的人-CSDN博客

【FDE系列】阶段1Day 17：FDE vs 传统实施 — 三大本质区别-CSDN博客

【FDE系列】阶段1Day 18：FDE 三重身份 + C6 胜任力模型-CSDN博客

【FDE系列】阶段1Day 19：七阶段行动路径 + 行业经验的价值-CSDN博客

【FDE系列】阶段1Day 20：阶段总结与产出物 — 第一阶段收官-CSDN博客

阶段二：技术地基（Python + FastAPI + SQL + Docker + API 集成）

Python基础

【FDE系列】阶段2：Day 21：Python 环境搭建 — 写出你的第一行代码-CSDN博客

【FDE系列】阶段2：Day 22：变量、数据类型、条件判断 — Python 的“记忆“和“判断“-CSDN博客

【FDE系列】阶段2：Day 23：循环与函数 — 让代码跑 100 遍、把逻辑打包复用-CSDN博客

【FDE系列】阶段2：Day 24：数据结构 — 列表、字典、集合、元组-CSDN博客

【FDE系列】阶段2：Day 25：文件读写与 JSON — 让程序连通外部数据（第一周收官）-CSDN博客

【FDE系列】阶段2：Day 26：模块化编程 — 把代码拆成“抽屉柜“-CSDN博客

【FDE系列】阶段2：Day 27：异常处理与日志 — 让程序“摔不烂、查得到“-CSDN博客

FastAPI入门到进阶

【FDE系列】阶段2：Day 28：FastAPI 入门 — 把你的函数变成 API 服务-CSDN博客

【FDE系列】阶段2：Day 29：FastAPI 进阶 — Pydantic 模型与完整 CRUD 实战-CSDN博客

【FDE系列】阶段2：Day 30：生产代码规范 — 测试、类型注解、配置管理（第二周收官）-CSDN博客

SQL基础

【FDE系列】阶段2：Day 31：SQL 基础 — 增删改查一把梭-CSDN博客

【FDE系列】阶段2：Day 32：多表查询 — JOIN 与聚合-CSDN博客

【FDE系列】阶段2：Day 33：进阶查询 — 窗口函数与 CTE-CSDN博客

【FDE系列】阶段2：Day 34：数据清洗 — 把脏数据捋干净-CSDN博客

【FDE系列】阶段2：Day 35：Python + SQL — 工单接入 MySQL + 本周收官-CSDN博客

Linux基础

【FDE系列】阶段2：Day 36：Linux 入门与文件操作 — 扔掉鼠标的第一天-CSDN博客

【FDE系列】阶段2：Day 37：权限、进程与文本三剑客-CSDN博客

【FDE系列】阶段2：Day 38：Shell 脚本 — 把命令串起来自动跑-CSDN博客

【FDE系列】阶段2：Day 39：Linux 综合实战 — 让服务无人值守-CSDN博客

【FDE系列】阶段2：Day 40：Shell 进阶 — 生产级脚本与本周收官-CSDN博客

Docker

【FDE系列】阶段2：Day 41：Docker 入门 — 把环境装进盒子-CSDN博客

【FDE系列】阶段2：Day 41（up详细版）：Docker 入门 — 把环境装进盒子-CSDN博客

【FDE系列】阶段2：Day 42：Dockerfile 实战 — 把你的应用打包成镜像-CSDN博客

【FDE系列】阶段2：Day 42（UP详细版）：Dockerfile 实战 — 把你的应用打包成镜像-CSDN博客

【FDE系列】阶段2：Day 43：Docker Compose — 多容器一键编排-CSDN博客

【FDE系列】阶段2：Day 43（UP详细版）：Docker Compose — 多容器一键编排-CSDN博客