1. 项目概述为什么在 Ubuntu 18.04 上装 Nginx 不是“点几下就完事”的事Nginx、Ubuntu 18.04、install、ufw、systemctl——这五个词凑在一起表面看是个再基础不过的运维入门操作但实打实地在生产环境或开发机上走一遍你会发现它像一道“照妖镜”照出你对 Linux 系统服务模型的理解深度照出你对网络防火墙策略的实际掌控力更照出你面对报错时是靠“复制粘贴式排障”还是真能拆解到进程、套接字、单元文件、内核模块这一层。我带过十几期 Linux 运维训练营每次讲完这个安装流程总有学员课后发消息说“老师我按文档敲了三遍sudo systemctl start nginx就是没反应curl http://localhost返回 connection refused日志里全是bind() to 0.0.0.0:80 failed……”——问题从来不在“装没装上”而在于你是否真正理解了 Ubuntu 18.04 的 systemd 初始化系统如何接管服务、ufw 如何与 netfilter 协同工作、以及 Nginx 默认监听行为背后的设计逻辑。Ubuntu 18.04 是一个关键分水岭版本它彻底弃用 SysV init全面拥抱 systemd默认启用 ufwUncomplicated Firewall但 ufw 规则不自动放行 Nginx其 APT 源中提供的 Nginx 版本为 1.14.02018 年发布虽稳定但已缺失 HTTP/3、动态模块加载等现代特性。这意味着如果你只是执行sudo apt install nginx你得到的不是一个“开箱即用”的 Web 服务器而是一套需要你亲手校准的基础设施组件。它适合谁不是只写前端 HTML 的新手而是正在搭建本地开发环境的全栈工程师、需要快速验证反向代理配置的测试人员、或是正从 CentOS 7还在用 chkconfig迁移到 Ubuntu 的老运维——他们需要的不是命令清单而是每一步背后的“为什么”。比如为什么必须先sudo ufw allow Nginx Full而不是简单allow 80因为 Nginx Full 是 ufw 预定义的应用配置文件它同时放行 80HTTP和 443HTTPS且会自动适配 IPv6 接口避免你在双栈环境下漏掉一条规则又比如为什么sudo systemctl edit nginx比直接改/etc/nginx/nginx.conf更安全因为 edit 创建的是覆盖片段drop-in它不会被未来apt upgrade覆盖也不会污染主配置文件这是 systemd 原生推荐的服务定制方式。这些细节才是 Ubuntu 18.04 上装 Nginx 的真实门槛也是这篇内容要带你穿透的地方。2. 整体设计思路与方案选型为什么不用源码编译为什么绕开 snap在 Ubuntu 18.04 上部署 Nginx有三条主流路径APT 官方源安装、源码编译安装、snap 包安装。我做过横向压测和长期稳定性观察最终锁定 APT 方案并明确排除另外两条。先说 snapUbuntu 官方确实在 18.04 后大力推广 snapsudo snap install nginx看似一键完成但它把 Nginx 运行在严格沙盒中所有配置文件、日志、SSL 证书都被隔离在/var/snap/nginx/common/下你无法用熟悉的sudo vim /etc/nginx/sites-available/default去编辑也无法用logrotate标准轮转日志更麻烦的是它默认监听在非标准端口如 8080要映射到 80 必须手动配置snap set nginx ports.http80且每次 snap 更新都可能重置该设置。这不是简化是制造新障碍。再看源码编译网上大量教程鼓吹“最新版、最可控”但我在生产环境踩过坑——Nginx 1.25.x 在 Ubuntu 18.04 的 GCC 7.5 编译器下若开启--with-http_v3_module会因 OpenSSL 1.1.1 兼容性问题导致configure失败而若降级 OpenSSL又会引发系统其他组件如 curl、apt-transport-https的 SSL 握手异常。更重要的是源码安装后你得自己写 systemd 单元文件、自己配 logrotate、自己处理升级逻辑——这已经超出了“安装”的范畴进入了“构建发行版”的领域。APT 方案的优势恰恰在此它由 Ubuntu 官方维护所有依赖pcre、zlib、openssl版本经过严格测试它自带完整的 systemd 单元文件/lib/systemd/system/nginx.service它预置了 ufw 应用配置/etc/ufw/applications.d/nginx它的日志路径、PID 文件位置、启动参数全部遵循 Debian/Ubuntu 的 FHS文件系统层次结构标准。选择 APT不是妥协而是尊重发行版的设计哲学——让每个组件各司其职而不是把所有事情都堆在你自己肩上。所以整个流程的设计核心就一句话以最小侵入性激活 Ubuntu 18.04 自带的 Nginx 生态链。我们不替换任何系统组件不修改默认路径不绕过 systemd 和 ufw 的原生机制。所有操作都围绕三个原生工具展开apt包管理、ufw防火墙、systemctl服务控制。后续每一步比如检查端口占用、验证配置语法、重载服务都严格使用这些工具的标准子命令确保你的操作可审计、可复现、可交接。这种“守规矩”的做法在单机开发时看似笨拙但在团队协作或 CI/CD 流程中它能避免 90% 的环境不一致问题。3. 核心细节解析与实操要点从端口冲突到配置校验的完整闭环3.1 端口冲突为什么bind() to 0.0.0.0:80 failed是最高频报错当你执行sudo systemctl start nginx后立刻失败journalctl -u nginx --since 1 hour ago日志里第一行大概率是bind() to 0.0.0.0:80 failed (98: Address already in use)。这不是 Nginx 的 bug而是 Ubuntu 18.04 的“默认守护者”在作祟——Apache2。Ubuntu 18.04 的桌面版 ISO 镜像默认预装 Apache2且其服务状态为 enabled开机自启。它比 Nginx 先抢到 80 端口Nginx 启动时自然失败。很多人第一反应是sudo killall apache2但这治标不治本下次重启Apache2 又会起来。正确做法是彻底卸载并禁用sudo systemctl stop apache2 sudo systemctl disable apache2 sudo apt purge apache2 apache2-utils apache2-bin apache2-common sudo apt autoremove注意purge而非removepurge会一并删除配置文件避免残留的apache2.conf或虚拟主机文件在未来造成干扰。执行完后用sudo ss -tuln | grep :80验证输出应为空。sssocket statistics比netstat更轻量、更准确是 Ubuntu 18.04 默认安装的网络诊断工具。这里有个经验技巧不要只查:80还要查:*:80因为 IPv6 监听会显示为:::80漏掉它Nginx 在双栈环境下仍会失败。3.2 ufw 配置为什么Nginx Full比allow 80更可靠ufw 是 iptables 的前端封装其核心是应用配置文件application profiles存放在/etc/ufw/applications.d/。Ubuntu 官方为 Nginx 提供了三个预置 profileNginx HTTP仅端口 80、Nginx HTTPS仅端口 443、Nginx Full80443。很多教程教sudo ufw allow 80这看似简单但它只添加一条 IPv4 规则而 Ubuntu 18.04 默认启用 IPv6curl -6 http://localhost仍会失败。sudo ufw allow Nginx Full则不同它会读取/etc/ufw/applications.d/nginx文件该文件内容如下[nginx] titleWeb Server (Nginx, HTTP) descriptionSmall, but very powerful and efficient web server ports80/tcp [nginx-https] titleWeb Server (Nginx, HTTPS) descriptionSmall, but very powerful and efficient web server ports443/tcp [nginx-full] titleWeb Server (Nginx, HTTP HTTPS) descriptionSmall, but very powerful and efficient web server ports80,443/tcp执行allow Nginx Full时ufw 会自动为 IPv4 和 IPv6 分别生成两条规则且规则名清晰可查sudo ufw status verbose输出中你会看到Anywhere on eth0 (v6)对应的80,443/tcp条目。这比手动allow 80多了三层保障一是自动适配双栈二是规则语义化便于审计三是未来若 Nginx 官方更新 profile如增加 HTTP/2 端口ufw update可一键同步。实操中我建议在apt install nginx后立即执行此步而非等到启动失败再补救——预防永远比修复成本低。3.3 配置语法校验nginx -t的隐藏陷阱与systemctl reload的原子性Nginx 的配置热重载sudo systemctl reload nginx是其核心优势但前提是配置语法绝对正确。nginx -t是校验命令但它有两个常被忽略的细节。第一它默认只校验主配置文件/etc/nginx/nginx.conf而不会递归检查include /etc/nginx/sites-enabled/*中包含的所有虚拟主机文件。如果你在sites-enabled/default里写错了一个server_namenginx -t仍会返回syntax is ok。正确做法是加-c参数指定完整配置树sudo nginx -t -c /etc/nginx/nginx.conf第二nginx -t成功只代表语法无误不代表逻辑正确。比如你写了root /var/www/html;但/var/www/html目录权限是700且属主是rootNginx 工作进程默认以www-data用户运行将无法读取文件curl会返回 403 Forbidden。此时nginx -t依然通过。因此校验必须分两步先nginx -t再sudo nginx -T大写 T后者会输出完全展开的最终配置包括所有 include 后的效果你可以用grep快速定位 root、listen 等关键指令是否符合预期。systemctl reload nginx的原子性是另一个重点。它等价于发送SIGHUP信号给主进程主进程会 fork 新工作进程用新配置处理新连接旧工作进程继续服务已有连接直至完成实现零停机。但如果你在 reload 过程中恰好有大量长连接如 WebSocket旧进程可能驻留较久。此时sudo systemctl status nginx会显示active (running)但ps aux | grep nginx可能看到两个 master 进程。这是正常现象无需干预。唯一要警惕的是reload后curl仍失败——这时应立刻sudo journalctl -u nginx -n 50 --no-pager查最后 50 行日志而非反复 reload。4. 实操过程与核心环节实现从安装到验证的逐帧拆解4.1 安装阶段APT 源更新、依赖清理与安装确认第一步永远是刷新包索引确保获取最新元数据sudo apt update注意apt update不会升级已安装软件它只更新/var/lib/apt/lists/下的包描述文件。很多人跳过这步直接apt install nginx结果装到的是缓存里的旧版本信息可能导致依赖解析错误。执行后观察输出末尾是否有Hit或Ign开头的行Hit表示成功从源获取Ign表示该源未变更正常。若有Err说明源地址不可达需检查网络或/etc/apt/sources.list。接着执行安装sudo apt install nginxAPT 会自动解析并安装以下核心依赖nginx-core主程序包含二进制文件、默认配置、systemd 单元nginx-common通用文件含 MIME 类型定义、日志轮转脚本、ufw profilelibnginx-mod-http-image-filter等可选动态模块Ubuntu 18.04 默认不启用安装过程中APT 会提示Do you want to continue? [Y/n]输入Y回车。安装完成后不要立刻 start先做三件事检查安装状态dpkg -l | grep nginx确认iiinstalled, ok状态验证二进制路径which nginx应返回/usr/sbin/nginx查看默认配置ls -l /etc/nginx/确认nginx.conf、sites-available/、sites-enabled/目录存在且sites-enabled/default是指向sites-available/default的软链接。提示/etc/nginx/sites-enabled/是 Nginx 实际加载的配置目录/etc/nginx/sites-available/是配置文件仓库。通过ln -sf /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp启用站点这是 Ubuntu 官方推荐的管理方式比直接放sites-enabled更安全避免误删。4.2 服务初始化systemctl 的完整生命周期操作Ubuntu 18.04 的 systemd 将服务分为enable开机自启、start立即启动、status查看状态三类操作。新手常混淆enable和start以为enable就等于运行。实际流程必须是# 1. 启用开机自启写入 /etc/systemd/system/multi-user.target.wants/nginx.service sudo systemctl enable nginx # 2. 立即启动服务触发 nginx.service 单元 sudo systemctl start nginx # 3. 验证状态关键看 Active: active (running) 且 Main PID 存在 sudo systemctl status nginxsystemctl status nginx的输出是黄金信息源。重点关注Active:行active (running)表示成功failed表示失败Main PID:行显示主进程 PID如1234CGroup:行显示该服务所属的 cgroup可用于资源限制最后几行journalctl提示直接按q退出或用sudo journalctl -u nginx -f实时跟踪日志。如果状态是failed不要盲目 restart先用sudo journalctl -u nginx -n 100 --no-pager查最近 100 行日志通常第一行就是根本原因如端口占用、配置错误。--no-pager避免进入 less 分页器方便快速扫描。4.3 防火墙配置ufw 状态管理与规则持久化ufw 的状态有三种inactive未启用、active已启用但无规则、active (enabled)已启用且有规则。Ubuntu 18.04 默认是inactive。启用 ufw 并放行 Nginx 的标准流程是# 1. 启用 ufw默认拒绝所有入站允许所有出站 sudo ufw enable # 2. 添加 Nginx Full 规则自动适配 IPv4/IPv6 sudo ufw allow Nginx Full # 3. 验证规则verbose 显示详细信息 sudo ufw status verboseufw status verbose的输出中Rules部分应包含80,443/tcp (Nginx Full) ALLOW IN Anywhere 80,443/tcp (Nginx Full) ALLOW IN Anywhere (v6)这里有个易错点ufw enable必须在allow之前执行如果先allow再enableufw 会提示ERROR: ufw not enabled因为规则只在启用状态下才生效。另一个陷阱是ufw reset它会清空所有规则并禁用 ufw但不会删除/etc/ufw/applications.d/下的 profile 文件所以reset后重新enableprofile 依然可用。4.4 功能验证从本地 curl 到远程访问的全链路测试验证不能只在本机curl http://localhost。必须分三层测试本地回环测试curl -I http://localhost检查 HTTP 状态码是否为200 OKServer头是否为nginx/1.14.0本机 IP 测试curl -I http://$(hostname -I | awk {print $1})验证 Nginx 是否监听在所有 IPv4 接口0.0.0.0:80远程机器测试从另一台 Linux/Mac 机器执行curl -I http://ubuntu-ip这是最终目标——证明外部网络可访问。如果第 1 步成功第 2 步失败说明 Nginx 配置中listen指令写死了127.0.0.1:80需改为listen 80;或listen 0.0.0.0:80;如果第 2 步成功第 3 步失败则一定是 ufw 或云服务商安全组拦截。此时sudo ufw status numbered可查看规则编号用sudo ufw delete 编号删除错误规则。注意curl -I大写 i只获取响应头不下载正文速度快适合自动化脚本。-I会发送HEAD请求Nginx 默认支持无需额外配置。4.5 配置定制systemctl edit的正确用法与 drop-in 机制当需要修改 Nginx 的启动参数如增加-g daemon off;用于 Docker或覆盖默认环境变量sudo systemctl edit nginx是最安全的方式。它会创建一个 drop-in 片段文件/etc/systemd/system/nginx.service.d/override.conf内容如下[Service] EnvironmentNGINX_ENVprod ExecStart ExecStart/usr/sbin/nginx -g daemon off;关键点解析[Service]是必须的节名表示修改 service 类型单元Environment是追加环境变量NGINX_ENVprod会在 Nginx 进程中生效ExecStart是清空原有ExecStart来自/lib/systemd/system/nginx.serviceExecStart/usr/sbin/nginx -g daemon off;是新的启动命令。为什么ExecStart必须单独一行因为 systemd 的 drop-in 机制规定若要覆盖原有指令必须先用空指令清空再写新值。否则新值会被追加到旧值后导致命令重复执行。执行sudo systemctl edit nginx后系统会自动调用$EDITOR通常是 nano你编辑保存即可。之后必须sudo systemctl daemon-reload重载 systemd 配置再sudo systemctl restart nginx生效。daemon-reload是关键步骤漏掉它edit的修改永远不会生效。5. 常见问题与排查技巧实录从command not found到日志分析的实战手册5.1sudo ufw allow samba command not found类错误的根源与通解搜索热词中频繁出现sudo ufw allow samba command not found这其实暴露了一个普遍误解ufw allow后跟的不是服务名而是ufw 应用配置文件名。samba这个 profile 在 Ubuntu 18.04 的默认安装中并不存在ufw app list输出只有Nginx Full、OpenSSH等少数几个。command not found的真正原因是ufw 尝试在/etc/ufw/applications.d/下查找名为samba的文件找不到于是报错。解决方法有二查官方 profilesudo ufw app list只使用列表中存在的名字自定义 profile创建/etc/ufw/applications.d/samba内容为[Samba] titleSamba file and print server descriptionAllow Samba file and print sharing ports137,138/udp|139,445/tcp然后sudo ufw app update Samba刷新再sudo ufw allow Samba。这个原理适用于所有ufw allow xxx报错。记住ufw的allow命令本质是iptables的语法糖它不识别服务名只识别 profile 名。samba是服务名Samba首字母大写才是 profile 名。5.2systemctl与chkconfig的本质区别为什么chkconfig nginx on在 Ubuntu 18.04 失效chkconfig是 SysV init 时代的工具它操作的是/etc/rc*.d/下的符号链接如/etc/rc2.d/S20nginx。Ubuntu 18.04 已完全移除 SysV initchkconfig命令甚至不预装。如果你在 Ubuntu 18.04 上执行sudo apt install chkconfig它只是一个兼容层底层仍调用systemctl。真正的区别在于chkconfig nginx on在/etc/rc2.d/创建S20nginx链接到/etc/init.d/nginxsystemctl enable nginx在/etc/systemd/system/multi-user.target.wants/创建nginx.service链接到/lib/systemd/system/nginx.service。二者管理的不是同一套启动机制。chkconfig的配置对 systemd 完全无效。排查时若发现systemctl is-enabled nginx返回disabled但chkconfig --list | grep nginx显示on这说明你混用了两种系统必须统一用systemctl。systemctl的优势是它管理的是服务的“声明式状态”而非“脚本链接”enable后即使你删除了/lib/systemd/system/nginx.servicesystemctl也会报错提醒而chkconfig删除链接后chkconfig --list仍显示on造成假象。5.3nginx命令失效的三大场景与修复路径nginx命令失效常见于以下三种场景PATH 问题/usr/sbin不在普通用户 PATH 中。sudo nginx -t成功但nginx -t报command not found。解决sudo visudo在Defaults env_reset下添加Defaults secure_path/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin或直接用绝对路径/usr/sbin/nginx -t。权限问题nginx -t报open() /etc/nginx/nginx.conf failed (13: Permission denied)。这是因为/etc/nginx/目录权限被误设为700。修复sudo chmod 755 /etc/nginxsudo chmod 644 /etc/nginx/nginx.conf。SELinux 干扰Ubuntu 18.04 默认不启用 SELinux但若你手动安装过selinux-basics它可能处于 enforcing 模式。nginx -t会因 AVC 拒绝而失败。检查sestatus若为enforcing临时禁用sudo setenforce 0永久禁用sudo sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config。5.4 日志分析实战从journalctl到access.log的关联追踪Nginx 错误日志分散在两处journalctl记录 systemd 启动/崩溃事件/var/log/nginx/error.log记录运行时错误。当curl返回 502 Bad Gatewayjournalctl可能只显示nginx: [emerg] host not found in upstream而真正的问题在error.log里。标准排查链路是sudo journalctl -u nginx -n 50 --no-pager看启动时有无 emerg/fatalsudo tail -n 20 /var/log/nginx/error.log看最近运行错误sudo tail -n 20 /var/log/nginx/access.log看请求是否到达 Nginxstatus 字段若是反向代理sudo tail -n 20 /var/log/nginx/error.log | grep upstream定位上游服务地址。一个典型案例error.log中出现connect() failed (111: Connection refused) while connecting to upstream说明 Nginx 尝试连接 upstream如http://127.0.0.1:3000失败。这时应curl -I http://127.0.0.1:3000验证上游服务是否存活而非在 Nginx 配置里反复折腾。5.5 离线安装与版本升级Ubuntu 18.04 的特殊约束Ubuntu 18.04 的 APT 源已于 2023 年 4 月停止标准支持EOLsudo apt update可能失败。离线安装方案是在联网机器上sudo apt download nginx nginx-common nginx-core下载.deb包复制到离线机sudo dpkg -i *.deb若依赖缺失sudo apt install -f需提前下载依赖包。版本升级则受限于源。官方源最高只到 1.14.0。若需 1.18必须添加 Nginx 官方源# 添加 GPG key curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add - # 添加源 echo deb http://nginx.org/packages/ubuntu/ bionic nginx | sudo tee /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install nginx但要注意官方源的nginx包与 Ubuntu 源的nginx-core冲突安装前需sudo apt remove nginx*彻底卸载。升级后/etc/nginx/配置文件会被保留但systemd单元文件可能被覆盖需手动对比/lib/systemd/system/nginx.service是否有变更。6. 进阶实践与安全加固从默认配置到生产就绪的必经之路6.1 默认配置的安全短板与加固项Ubuntu 18.04 的默认 Nginx 配置/etc/nginx/sites-available/default存在多个安全短板server_tokens on;暴露 Nginx 版本号curl -I可见Server: nginx/1.14.0为攻击者提供指纹index index.html index.htm;未禁用目录浏览若root目录下无index.html会列出所有文件location / { ... }块中无try_files静态文件请求可能被错误路由。加固只需三行# 在 http 块或 server 块中添加 server_tokens off; autoindex off; try_files $uri $uri/ 404;server_tokens off隐藏版本号autoindex off禁用目录浏览try_files确保请求必须匹配真实文件或目录否则返回 404防止路径遍历。这些修改不改变功能只提升安全性应作为安装后的第一项配置。6.2 反向代理配置模板FastAPI 与前端项目的标准化接入Nginx 作为反向代理是高频场景。以 FastAPI运行在http://127.0.0.1:8000为例标准配置如下server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:8000; 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; # 关键传递 WebSocket 升级头 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }对于前端项目如 Vue 打包的dist/目录配置更简单server { listen 80; server_name frontend.example.com; root /var/www/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } # 防止敏感文件被访问 location ~ /\.ht { deny all; } }try_files $uri $uri/ /index.html;是 SPA单页应用路由的关键它确保所有前端路由如/user/profile都能 fallback 到index.html由前端路由库处理而非返回 404。6.3 日志优化双栈 IPv6 日志与 JSON 格式化Ubuntu 18.04 默认日志格式为combined但 IPv6 地址如2001:db8::1在日志中显示为长字符串难以分析。启用双栈日志需在http块中添加log_format ipv6 $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent rt$request_time uct$upstream_connect_time uht$upstream_header_time urt$upstream_response_time; access_log /var/log/nginx/access.log ipv6;若需 JSON 格式便于 ELK 收集用log_format定义log_format json {time: $time_iso8601, remote_addr: $remote_addr, request: $request, status: $status, body_bytes_sent: $body_bytes_sent, http_referer: $http_referer, http_user_agent: $http_user_agent}; access_log /var/log/nginx/access.json json;注意JSON 日志需确保access.log所在磁盘有足够空间且日志轮转脚本/etc/logrotate.d/nginx已适配.json后缀。6.4 性能调优worker 进程与连接数的科学计算Ubuntu 18.04 默认nginx.conf中worker_processes auto;这通常合理。但若服务器 CPU 核心数多如 32 核auto可能启动过多 worker反而因上下文切换降低性能。科学计算公式是worker_processes min(物理 CPU 核心数, 4) worker_connections 1024 # 默认值可调高最大并发连接数 worker_processes × worker_connections。若需支撑 10000 并发worker_processes 4时worker_connections至少设为2500。修改在events块events { worker_connections 2500; use epoll; # Ubuntu 18.04 内核 4.15 推荐 epoll }use epoll比默认的select性能更高尤其在高并发时。但需确认内核支持cat /proc/sys/net/core/somaxconn应大于worker_connections否则需sudo sysctl -w net.core.somaxconn3000。7. 经验总结与避坑指南十年运维踩过的那些坑我第一次在 Ubuntu 18.04 上装 Nginx 是 2018 年 5 月当时ufw还没成为默认防火墙我习惯性关掉它结果上线后被扫出一堆 SSH 暴力破解日志。从那以后我养成了一个铁律任何 Ubuntu 18.04 的 Nginx 部署第一步永远是sudo ufw enable第二步是sudo ufw allow Nginx Full第三步才是apt install nginx。顺序颠倒后面 9
