企业官网建设流程全解析

1. 这不是“一键配置”，而是把三件高耦合的事拧成一股绳

你搜“nginx泛域名转发+https配置+内网穿透”，大概率是正卡在某个深夜：本地跑着一个Spring Boot服务，前端静态资源放在另一台机器上，测试域名得临时配hosts，客户要看演示又急着要https，而你手里的服务器只有个内网IP——这时候，网上那些“5分钟搞定”的教程，往往只讲其中一环，结果你配完泛域名，发现证书不生效；证书搞定了，反向代理却把Host头丢了；代理通了，HTTPS又报ERR_SSL_PROTOCOL_ERROR。这不是你技术不行，是这三件事天然咬合：泛域名解决的是路由入口的弹性问题，HTTPS解决的是传输链路的信任问题，内网穿透解决的是网络拓扑的可达性问题。它们不是并列关系，而是层层嵌套的依赖链——没有泛域名，你就得为每个子域单独写server块，运维成本指数级上升；没有HTTPS，现代浏览器直接拦截混合内容，连前端JS都可能加载失败；没有内网穿透，你连让外部流量抵达Nginx这第一步都迈不出去。我去年帮一家做IoT设备管理平台的团队重构网关层，他们原来用三个独立脚本分别处理这三件事，每次加新设备就得手动改三处配置、重启三次服务、验证五次证书状态，平均耗时47分钟。后来我们把逻辑压进一套配置模板里，配合自动化证书续期和穿透隧道健康检查，现在新增一个子域（比如device-00123.example.com）从提交到可用，全程22秒，且零人工干预。核心不是工具多高级，而是理解这三件事在数据流中的真实位置：请求进来时，DNS先解析到你的公网IP（穿透终点），Nginx拿到Host头后按泛域名规则匹配server块，再用SNI信息选择对应证书完成TLS握手，最后把解密后的HTTP请求按proxy_pass转发到内网目标。任何一个环节断开，整条链就瘫痪。所以这篇不讲“怎么装nginx”，而是带你亲手把这根链条锻造成型——每一步都标清楚为什么这么选、踩过什么坑、参数背后的真实含义。

2. 整体架构设计与方案选型逻辑

2.1 为什么必须用Nginx而不是其他反向代理？

很多人看到“内网穿透”第一反应是frp或ngrok，但它们本质是TCP层隧道，无法原生处理HTTP/HTTPS的语义。比如泛域名需要解析Host头，而frp默认只做端口映射，你得在frp客户端额外加一层Nginx才能实现host-based routing；ngrok虽然支持自定义域名，但免费版强制带ngrok.io后缀，且证书由ngrok托管，你无法控制证书有效期和SAN字段。Nginx的优势在于它处在七层（应用层），能同时完成三件事：

• 泛域名匹配：通过server_name *.example.com指令，配合正则提取子域名（如$1捕获api或admin），动态构造上游地址；
• HTTPS终止：利用OpenSSL库直接处理TLS握手，支持ACME协议自动申请Let’s Encrypt证书，且证书可绑定到具体server块；
• 内网穿透适配：当穿透工具（如frp）把公网端口映射到本地Nginx监听端口时，Nginx作为穿透链路的“终结者”，负责把加密流量解包、路由、再转发，避免在穿透层重复加密。

提示：不要用Cloudflare等CDN做中间层来替代Nginx的HTTPS终止。CDN虽然能提供免费证书，但它会把原始Client IP变成CDN节点IP，导致Nginx日志里全是103.x.x.x，且无法获取真实的SNI信息——而泛域名转发恰恰依赖SNI来选择证书。必须让Nginx直面公网流量。

2.2 泛域名转发的两种实现路径对比

泛域名转发不是简单写个*.example.com就能万事大吉。实际部署中，你要面对两个关键问题：子域名如何映射到不同后端？和如何避免通配符证书覆盖所有子域带来的安全风险？

我最终采用动态变量路由+白名单校验组合：

• 先用server_name *.example.com;捕获所有请求；
• 用正则~^([a-zA-Z0-9\-]+)\.example\.com$提取子域名到$1变量；
• 设置白名单数组map $1 $backend { default "invalid"; "api" "http://192.168.1.10:8080"; "admin" "http://192.168.1.11:3000"; }；
• proxy_pass $backend;，若匹配失败则返回444（Nginx特有关闭连接状态码，比404更安全）。
  这样既保证灵活性，又杜绝恶意子域（如hacker.example.com）被错误路由。

2.3 HTTPS配置的核心陷阱：SNI与ALPN必须同步启用

很多教程教你怎么用certbot申请证书，却没告诉你：Nginx的HTTPS配置里，SNI（Server Name Indication）和ALPN（Application-Layer Protocol Negotiation）必须同时开启，否则HTTP/2会静默降级。

SNI的作用是让客户端在TLS握手初期就告诉服务器“我要访问哪个域名”，这样Nginx才能从多个证书中选出正确的那个。而ALPN是协商应用层协议（HTTP/1.1 or HTTP/2）的机制。如果只开SNI不开ALPN，Chrome最新版会拒绝HTTP/2连接，导致页面加载变慢。

实测对比（同一台服务器，相同证书）：

• 仅配置ssl_protocols TLSv1.2 TLSv1.3;→ Chrome DevTools显示Protocol: h2（HTTP/2）；
• 加上ssl_prefer_server_ciphers on;但未启用ALPN →Protocol: http/1.1；
• 正确配置ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off;→Protocol: h2稳定生效。

原因在于：ssl_prefer_server_ciphers on会强制使用服务器端cipher suite，而某些旧cipher不支持ALPN协商。Nginx官方文档明确建议off，让客户端选择最优cipher。

注意：不要盲目复制网上“加固配置”。像ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'这种写法，虽看似安全，但会排除iOS 14以下设备的支持，导致部分用户白屏。生产环境推荐用Mozilla的Intermediate配置（https://wiki.mozilla.org/Security/Server_Side_TLS），它平衡了兼容性与安全性。

2.4 内网穿透工具选型：frp vs. 自建穿透网关

当前主流穿透方案有frp、ngrok、localtunnel，但结合Nginx泛域名+HTTPS，frp是唯一合理选择。理由很实在：

• ngrok免费版不支持自定义域名，且证书不可控；
• localtunnel是单端口映射，无法承载Nginx的多server块；
• frp的vhost_http_port模式允许将HTTP Host头透传给内网Nginx，这是实现泛域名的关键。

frp的配置分两段：

• 服务端（公网服务器）：运行frps，监听7000（控制端口）和80/443（HTTP/HTTPS端口）；
• 客户端（内网机器）：运行frpc，将本地Nginx的80/443端口映射到frps的80/443。

关键点在于frpc的[web]配置：

[web] type = http local_port = 80 custom_domains = example.com # 必须开启这个！否则Host头丢失 host_header_rewrite = example.com

host_header_rewrite确保frp把原始Host头（如api.example.com）重写为example.com，再由内网Nginx的泛域名server块二次解析。如果不设，Nginx收到的Host头是example.com，所有请求都路由到默认server块，泛域名失效。

3. 核心细节解析与实操要点

3.1 Nginx泛域名配置的底层逻辑与正则陷阱

泛域名配置看似简单，但server_name *.example.com;背后藏着几个致命细节：

第一，通配符只匹配一级子域。*.example.com能匹配api.example.com、admin.example.com，但不能匹配dev.api.example.com。如果你需要三级域名，必须用正则：server_name ~^(?<subdomain>.+)\.example\.com$;，然后用$subdomain变量提取完整前缀。

第二，正则捕获组命名必须用?<name>语法。网上很多教程写~^([a-z]+)\.example\.com$，结果$1取不到值——因为Nginx 1.11+要求命名捕获组，否则变量为空。正确写法：~^(?<subdomain>[a-z0-9\-]+)\.example\.com$。

第三，子域名合法性校验不能只靠正则。正则[a-z0-9\-]+允许--test这样的非法名称，而DNS规范要求子域名不能以连字符开头或结尾，且长度1-63字符。我在白名单map前加了一层校验：

# 提取子域名并清理 if ($host ~* ^([a-z0-9][a-z0-9\-]{0,61}[a-z0-9])\.example\.com$) { set $clean_subdomain $1; } # 若未匹配，跳转到错误页 if ($clean_subdomain = "") { return 444; }

这里用if配合正则，确保$clean_subdomain只含合法字符，再交给map做路由。

第四，泛域名server块必须放在default server之后。Nginx按server块顺序匹配，如果泛域名块写在最前面，它会吃掉所有未明确指定的域名请求，包括你本想用作管理后台的nginx.example.com。标准顺序：

1. default server（处理无Host头或未知域名）；
2. 明确命名的server（如www.example.com、api.example.com）；
3. 泛域名server（*.example.com）。

3.2 HTTPS证书自动续期的可靠方案

Let’s Encrypt证书90天过期，手动续期等于埋雷。但certbot renew命令在crontab里执行常失败，原因有三：

• 权限问题：crontab默认PATH不包含certbot路径，需写绝对路径/usr/local/bin/certbot renew；
• Webroot冲突：certbot用webroot插件验证域名时，若Nginx正在运行，可能因端口占用失败；
• 钩子脚本时机错误：--deploy-hook在续期成功后执行，但Nginx重载必须在证书文件真正写入磁盘后。

我的解决方案是双钩子+原子操作：

# /etc/cron.d/certbot 0 2 * * 1 /usr/local/bin/certbot renew --quiet --no-self-upgrade \ --deploy-hook "/usr/local/bin/nginx-reload.sh"

nginx-reload.sh内容：

#!/bin/bash # 等待证书文件完全写入（inotifywait监听） /usr/bin/inotifywait -q -e moved_to /etc/letsencrypt/live/example.com/ -t 30 || exit 1 # 原子性重载：先测试配置，再重载 /usr/sbin/nginx -t && /usr/sbin/nginx -s reload

inotifywait确保Nginx只在证书文件真正就绪后才重载，避免重载时读到半截证书。

实操心得：不要用--standalone模式。它需要Nginx停止监听80/443端口，导致服务中断。--webroot模式只需在Nginx配置里加一个location：

location ^~ /.well-known/acme-challenge/ { alias /var/www/.well-known/acme-challenge/; allow all; }

certbot会把验证文件放到该目录，Nginx直接返回，全程不影响业务。

3.3 内网穿透的端口映射与健康检查

frp穿透不是“配完就完事”，必须加入健康检查机制，否则frp客户端崩溃后，Nginx还在往已断开的连接发请求，导致502错误。

frps服务端配置（/etc/frp/frps.ini）关键项：

[common] bind_port = 7000 vhost_http_port = 80 vhost_https_port = 443 # 启用dashboard，方便监控 dashboard_port = 7500 dashboard_user = admin dashboard_pwd = your_strong_password # 心跳超时，客户端每30秒发心跳 heartbeat_timeout = 90

frpc客户端配置（/etc/frp/frpc.ini）关键项：

[common] server_addr = your_public_ip server_port = 7000 # 客户端健康检查：每10秒ping一次frps health_check_type = tcp health_check_timeout_s = 3 health_check_interval_s = 10 health_check_max_failed = 3 [web-http] type = http local_port = 80 custom_domains = example.com # 关键！透传Host头 host_header_rewrite = example.com [web-https] type = https local_port = 443 custom_domains = example.com

Nginx侧的容错配置：

upstream frp_backend { server 127.0.0.1:8080; # frp客户端监听端口 # 连接失败时，尝试次数和超时 keepalive 32; } server { listen 80; server_name *.example.com; # 所有HTTP请求301跳转HTTPS return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name *.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # 若frp客户端宕机，Nginx快速失败而非长等待 proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; proxy_next_upstream_tries 3; proxy_next_upstream_timeout 3s; location / { proxy_pass http://frp_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; } }

proxy_next_upstream让Nginx在frp客户端不可用时，自动重试或返回错误，避免用户长时间等待。

4. 实操过程与核心环节实现

4.1 环境准备：从零开始搭建Nginx+frp穿透链

假设你有一台公网云服务器（Ubuntu 22.04）和一台内网开发机（CentOS 7），按以下步骤操作：

步骤1：公网服务器安装Nginx与frps

# 更新系统 sudo apt update && sudo apt upgrade -y # 安装Nginx（官方源，非apt默认版本） curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg echo "deb [arch=amd64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install nginx -y # 安装frps（最新版） wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz tar -xzf frp_0.54.0_linux_amd64.tar.gz sudo mkdir -p /etc/frp sudo cp frp_0.54.0_linux_amd64/frps /usr/local/bin/ sudo cp frp_0.54.0_linux_amd64/frps_full.ini /etc/frp/frps.ini

步骤2：配置frps并设为systemd服务
编辑/etc/frp/frps.ini：

[common] bind_port = 7000 kcp_bind_port = 7000 vhost_http_port = 80 vhost_https_port = 443 dashboard_port = 7500 dashboard_user = admin dashboard_pwd = ChangeMe123! token = YourStrongTokenHere max_pool_count = 50

创建systemd服务：

sudo tee /etc/systemd/system/frps.service << 'EOF' [Unit] Description=Frp Server Service After=network.target [Service] Type=simple User=root Restart=on-failure RestartSec=5 ExecStart=/usr/local/bin/frps -c /etc/frp/frps.ini [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable frps sudo systemctl start frps

步骤3：内网开发机安装frpc与Nginx

# CentOS 7安装Nginx（EPEL源） sudo yum install epel-release -y sudo yum install nginx -y # 安装frpc wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz tar -xzf frp_0.54.0_linux_amd64.tar.gz sudo mkdir -p /etc/frp sudo cp frp_0.54.0_linux_amd64/frpc /usr/local/bin/ sudo cp frp_0.54.0_linux_amd64/frpc_full.ini /etc/frp/frpc.ini

步骤4：配置frpc并启动
编辑/etc/frp/frpc.ini：

[common] server_addr = your_public_ip server_port = 7000 token = YourStrongTokenHere [web-http] type = http local_port = 80 custom_domains = example.com host_header_rewrite = example.com [web-https] type = https local_port = 443 custom_domains = example.com

启动frpc：

sudo systemctl enable nginx sudo systemctl start nginx # 启动frpc（前台测试） /usr/local/bin/frpc -c /etc/frp/frpc.ini # 成功后Ctrl+C，再设为服务 sudo tee /etc/systemd/system/frpc.service << 'EOF' [Unit] Description=Frp Client Service After=network.target [Service] Type=simple User=root Restart=on-failure RestartSec=5 ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.ini [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable frpc sudo systemctl start frpc

4.2 Nginx泛域名+HTTPS核心配置文件详解

这是最终生效的/etc/nginx/conf.d/example.com.conf：

# 默认server，处理未知域名或无Host头请求 server { listen 80 default_server; listen 443 ssl http2 default_server; server_name _; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; return 444; } # www重定向到根域名 server { listen 80; server_name www.example.com; return 301 https://example.com$request_uri; } server { listen 443 ssl http2; server_name www.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; return 301 https://example.com$request_uri; } # 根域名主站 server { listen 80; server_name example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; root /var/www/html; index index.html; location / { try_files $uri $uri/ =404; } } # 泛域名转发（核心） server { listen 80; server_name *.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name *.example.com; # 证书（通配符证书） ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # SNI与ALPN关键配置 ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers off; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; # 提取子域名并校验 if ($host ~* ^([a-z0-9][a-z0-9\-]{0,61}[a-z0-9])\.example\.com$) { set $clean_subdomain $1; } if ($clean_subdomain = "") { return 444; } # 白名单路由 map $clean_subdomain $backend { default "http://127.0.0.1:8080"; # 默认后端 "api" "http://192.168.1.10:8080"; "admin" "http://192.168.1.11:3000"; "docs" "http://192.168.1.12:3001"; } # 反向代理设置 location / { proxy_pass $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; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; # 超时与重试 proxy_connect_timeout 5s; proxy_send_timeout 30s; proxy_read_timeout 30s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504; proxy_next_upstream_tries 3; proxy_next_upstream_timeout 5s; } }

配置生效命令：

# 测试配置语法 sudo nginx -t # 重载Nginx（不中断服务） sudo nginx -s reload # 检查frp状态 curl -u admin:ChangeMe123! http://localhost:7500/api/status

4.3 Let’s Encrypt证书申请与验证流程

申请通配符证书必须用DNS验证，因为HTTP验证无法覆盖*.example.com。但DNS验证需要API密钥，我们用cloudflare插件简化：

步骤1：安装certbot与cloudflare插件

sudo apt install python3-certbot-dns-cloudflare -y

步骤2：创建cloudflare API密钥

• 登录Cloudflare，进入Account > API Tokens；
• 创建Token，权限设为Zone.Zone:Read, Zone.DNS:Edit；
• 复制Token，保存到/root/.secrets/cloudflare.ini：

dns_cloudflare_api_token = your_cloudflare_api_token_here

权限设为600：chmod 600 /root/.secrets/cloudflare.ini

步骤3：申请证书

sudo certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \ --dns-cloudflare-propagation-seconds 30 \ -d example.com \ -d "*.example.com" \ --email your@email.com \ --agree-tos \ --non-interactive

--dns-cloudflare-propagation-seconds 30确保DNS记录全球生效后再验证，避免失败。

证书位置：

• 公钥：/etc/letsencrypt/live/example.com/fullchain.pem
• 私钥：/etc/letsencrypt/live/example.com/privkey.pem
• 中间证书：/etc/letsencrypt/live/example.com/chain.pem

注意：不要用--standalone或--webroot申请通配符证书，它们不支持*域名验证。DNS验证是唯一合规方式。

5. 常见问题与排查技巧实录

5.1 泛域名不生效：90%是Host头丢失或正则错误

现象：访问api.example.com，Nginx日志显示404或502，但curl -H "Host: api.example.com" http://your_ip返回正常。

排查步骤：

1. 确认frp是否透传Host头：

   # 在内网Nginx服务器上抓包 sudo tcpdump -i lo port 80 -A | grep "Host:" # 若看到Host: example.com，则frp未正确配置host_header_rewrite

2. 检查Nginx server_name匹配：

   # 查看Nginx实际加载的server块 sudo nginx -T 2>&1 | grep -A 5 "server_name" # 确保泛域名块存在且顺序正确

3. 验证正则提取：
   在配置中临时加日志：

   log_format debug '$remote_addr - $host $clean_subdomain $backend'; access_log /var/log/nginx/debug.log debug;

   访问后查看/var/log/nginx/debug.log，若$clean_subdomain为空，说明正则未匹配。

终极修复：

• 确保frpc配置有host_header_rewrite = example.com；
• Nginx泛域名server块必须用server_name *.example.com;，而非server_name example.com;；
• 正则必须用命名捕获组~^(?<subdomain>[a-z0-9\-]+)\.example\.com$。

5.2 HTTPS证书报错：ERR_SSL_PROTOCOL_ERROR的三大根源

现象：浏览器提示NET::ERR_CERT_COMMON_NAME_INVALID或ERR_SSL_PROTOCOL_ERROR。

根源与修复：

快速验证命令：

# 检查证书有效期 openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -dates -noout # 检查证书链完整性 curl -I https://example.com --resolve "example.com:443:your_public_ip" # 模拟SNI握手 openssl s_client -connect your_public_ip:443 -servername api.example.com -showcerts

5.3 内网穿透中断：frp客户端自动退出的诊断清单

现象：frpc进程消失，systemctl status frpc显示failed，但日志无明显错误。

排查清单：

1. 内存溢出：frpc默认内存限制低，大量并发时OOM。在frpc.ini加：

   [common] # 增加内存限制 max_pool_count = 100 # 减少日志级别降低IO log_level = warn

2. 网络波动导致心跳超时：frps的heartbeat_timeout设为90秒，但frpc的health_check_interval_s设为10秒，若网络延迟>10秒，frpc会误判为宕机。调整为：

   health_check_interval_s = 30 health_check_timeout_s = 10

3. 端口冲突：frpc的local_port = 80与内网Nginx冲突。解决方案：

   • 改frpc监听端口：local_port = 8080；
   • Nginx proxy_pass指向http://127.0.0.1:8080；
   • 确保内网Nginx不监听80端口（只监听8080）。

frpc崩溃日志定位：

# 查看最近100行日志 sudo journalctl -u frpc -n 100 -f # 若看到"panic: runtime error"，则是frp bug，升级到v0.54.0+

5.4 性能瓶颈：Nginx并发连接数调优实战

当并发用户超500，出现502 Bad Gateway或响应延迟，不是frp问题，而是Nginx连接池不足。

关键参数调优：

# /etc/nginx/nginx.conf events { worker_connections 4096; # 每worker进程最大连接数 use epoll; # Linux高效IO模型 } http { # 连接复用 keepalive_timeout 65; keepalive_requests 100; # upstream优化 upstream backend { least_conn; # 最少连接算法 server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; # 增加连接池 keepalive 32; } # 客户端超时 client_header_timeout 10; client_body_timeout 10; send_timeout 10; }

系统级调优：

# 增加系统文件描述符限制 echo "* soft nofile 65536" | sudo tee -a /etc/security/limits.conf echo "* hard nofile 65536" | sudo tee -a /etc/security/limits.conf # 生效需重启shell或reboot # 增加网络连接队列 echo 'net.core.somaxconn = 65535' | sudo tee -a /etc/sysctl.conf sudo sysctl -p

压测验证：

# 用ab模拟1000并发 ab -n 10000 -c 1000 https://api.example.com/health # 观察Nginx状态页（需启用stub_status） curl http://localhost/nginx_status

若Active connections接近worker_connections，说明需继续调优。

6. 实战经验总结：那些文档不会写的