Nginx性能调优20条黄金法则:支撑10万并发的配置模板
一、概述
1.1 背景介绍
说实话,Nginx调优这事儿我踩过无数坑。记得2019年双11,我们电商平台流量暴涨,Nginx直接扛不住了,QPS从平时的2万飙升到8万,响应时间从50ms飙到了2秒,最后还是靠临时加机器扛过去的。那次事故之后,我花了大半年时间专门研究Nginx的性能极限,总结出了这20条黄金法则。
Nginx作为目前最流行的Web服务器和反向代理,官方数据显示单机可以轻松处理10万+的并发连接。但实际生产环境中,很多同学拿到默认配置就直接上了,结果发现连1万并发都扛不住。问题不在Nginx本身,而在于配置。
1.2 技术特点
Nginx采用事件驱动的异步非阻塞架构,这跟传统的Apache每个连接一个进程/线程的模式完全不同。打个比方:Apache像是银行柜台,每个客户都需要一个柜员全程服务;Nginx则像是叫号系统,一个柜员可以同时处理多个客户的不同阶段任务。
核心优势:
- 内存占用低:处理10000个非活跃HTTP keep-alive连接仅需2.5MB内存
- 事件驱动:基于epoll/kqueue,不会因为连接数增加而线性增长CPU消耗
- 模块化设计:只加载需要的模块,减少资源浪费
- 热部署:配置修改无需重启,平滑reload
1.3 适用场景
- 高并发静态资源服务(图片、CSS、JS、视频)
- 反向代理和负载均衡
- API网关
- SSL/TLS终结点
- 缓存服务器
- WebSocket代理
1.4 环境要求
| 组件 | 版本 | 说明 |
|---|---|---|
| 操作系统 | Rocky Linux 9.4 / Ubuntu 24.04 LTS | 内核版本建议5.15+ |
| Nginx | 1.26.2 / 1.27.0 | mainline版本功能更新,stable版本更稳定 |
| CPU | 8核+ | Nginx worker数量与CPU核心数相关 |
| 内存 | 16GB+ | 主要用于连接缓冲和缓存 |
| 网络 | 万兆网卡 | 千兆网卡在高并发下会成为瓶颈 |
| 磁盘 | NVMe SSD | 日志写入和缓存需要高IOPS |
二、详细步骤
2.1 准备工作
2.1.1 系统内核参数调优
在动Nginx配置之前,得先把操作系统底子打好。很多人忽略了这一步,结果Nginx配得再好也白搭。
# /etc/sysctl.conf 追加以下内容
# 文件描述符限制
fs.file-max = 2097152
fs.nr_open = 2097152
# TCP连接相关
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 65535
# TIME_WAIT优化(这个参数救过我无数次)
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 262144
# TCP keepalive
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3
# 网络缓冲区
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 本地端口范围
net.ipv4.ip_local_port_range = 1024 65535应用配置:
sysctl -p2.1.2 文件描述符限制
这是个老生常谈的问题了,但每次接手新项目还是会遇到。Nginx报"Too many open files"错误,十有八九就是这个没配好。
# /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576
nginx soft nofile 1048576
nginx hard nofile 1048576
# /etc/systemd/system/nginx.service.d/override.conf
[Service]
LimitNOFILE=10485762.2 核心配置
法则1:worker进程数量配置
# 自动检测CPU核心数,省心省力
worker_processes auto;
# 或者手动指定,建议等于CPU核心数
# worker_processes 8;
# CPU亲和性绑定,减少CPU缓存失效
worker_cpu_affinity auto;踩坑记录:早期我喜欢把worker_processes设成CPU核心数的2倍,觉得这样能处理更多请求。结果发现这是典型的过度优化,多出来的worker进程反而增加了上下文切换开销,QPS不升反降。
法则2:worker连接数配置
events {
# 每个worker的最大连接数
# 理论最大并发 = worker_processes * worker_connections
worker_connections 65535;
# 使用epoll事件模型(Linux 2.6+必选)
use epoll;
# 允许一个worker进程同时接受多个新连接
multi_accept on;
# 互斥锁,高并发场景建议关闭
accept_mutex off;
}法则3:文件描述符缓存
# main context
worker_rlimit_nofile 1048576;法则4:sendfile零拷贝
http {
# 开启sendfile,避免用户态和内核态之间的数据拷贝
sendfile on;
# 配合sendfile使用,减少网络报文段数量
tcp_nopush on;
# 禁用Nagle算法,减少延迟
tcp_nodelay on;
}原理解释:传统文件发送需要经历"磁盘->内核缓冲区->用户缓冲区->socket缓冲区"四次拷贝。sendfile直接在内核态完成"磁盘->socket缓冲区"的数据传输,理论上可以提升30%-40%的吞吐量。
法则5:超时配置
http {
# 客户端请求头超时
client_header_timeout 15s;
# 客户端请求体超时
client_body_timeout 15s;
# 响应超时
send_timeout 15s;
# keepalive超时
keepalive_timeout 65s;
# keepalive请求数量限制
keepalive_requests 10000;
}踩坑记录:曾经有个项目,上传大文件总是失败。排查半天发现是client_body_timeout设成了10秒,但大文件上传需要更长时间。生产环境这个值建议根据实际业务调整,不要一刀切。
法则6:缓冲区配置
http {
# 客户端请求体缓冲区
client_body_buffer_size 128k;
client_max_body_size 100m;
# 请求头缓冲区
client_header_buffer_size 4k;
large_client_header_buffers 4 32k;
# 代理缓冲区
proxy_buffer_size 64k;
proxy_buffers 8 128k;
proxy_busy_buffers_size 256k;
}法则7:Gzip压缩
http {
gzip on;
gzip_vary on;
gzip_proxied any;
# 压缩级别1-9,建议4-6,太高CPU消耗大
gzip_comp_level 5;
# 最小压缩长度,太小的文件压缩反而浪费CPU
gzip_min_length 1024;
# 压缩类型
gzip_types
text/plain
text/css
text/javascript
application/javascript
application/json
application/xml
application/xml+rss
image/svg+xml;
# 预压缩文件支持
gzip_static on;
}性能对比:
| 压缩级别 | 压缩率 | CPU消耗 | 适用场景 |
|---|---|---|---|
| 1 | 低 | 最低 | CPU受限环境 |
| 4-5 | 中 | 中等 | 通用场景(推荐) |
| 9 | 高 | 最高 | 带宽极其昂贵 |
法则8:静态文件缓存
http {
# 打开文件缓存
open_file_cache max=100000 inactive=60s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
}
server {
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
expires 30d;
add_header Cache-Control "public, immutable";
access_log off;
}
}法则9:日志优化
http {
# 使用缓冲写入,减少磁盘IO
access_log /var/log/nginx/access.log main buffer=64k flush=5s;
# 或者对于高并发场景,考虑关闭access log
# access_log off;
# 错误日志级别
error_log /var/log/nginx/error.log warn;
}血泪教训:生产环境日志不要开debug级别!我曾经为了排查问题临时开了debug,结果磁盘一会儿就满了,服务直接挂掉。
法则10:SSL/TLS优化
http {
# SSL会话缓存
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;
# SSL协议版本
ssl_protocols TLSv1.2 TLSv1.3;
# 优先使用服务器端加密套件
ssl_prefer_server_ciphers off;
# TLS 1.3加密套件
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
}法则11:HTTP/2配置
server {
listen 443 ssl;
http2 on;
# HTTP/2推送(Nginx 1.25.1+)
# 注意:主流浏览器已逐步废弃Server Push
}法则12:连接复用优化
upstream backend {
server 10.0.0.1:8080;
server 10.0.0.2:8080;
# 与后端保持的连接数
keepalive 300;
# 单个连接最大请求数
keepalive_requests 10000;
# 连接超时
keepalive_timeout 60s;
}
server {
location /api/ {
proxy_pass http://backend;
# 必须使用HTTP/1.1才能使用keepalive
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}这条救命配置:很多人配了upstream的keepalive但不生效,99%是因为没加proxy_set_header Connection ""。默认情况下Nginx会把Connection头设成close,导致每次请求都新建连接。
法则13:负载均衡算法选择
upstream backend {
# 最少连接数算法,推荐
least_conn;
# 或者IP哈希(需要会话保持时使用)
# ip_hash;
# 或者一致性哈希
# hash $request_uri consistent;
server 10.0.0.1:8080 weight=3;
server 10.0.0.2:8080 weight=2;
server 10.0.0.3:8080 weight=1 backup;
}法则14:健康检查
upstream backend {
server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
}开源版Nginx的健康检查比较弱,只能被动检测。如果需要主动健康检查,建议:
- 使用Nginx Plus(商业版)
- 使用第三方模块nginx_upstream_check_module
- 使用OpenResty
法则15:请求限流
http {
# 定义限流区域
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
}
server {
location /api/ {
# 请求速率限制
limit_req zone=api_limit burst=200 nodelay;
# 并发连接限制
limit_conn conn_limit 50;
# 限流返回码
limit_req_status 429;
limit_conn_status 429;
}
}法则16:proxy优化
location /api/ {
proxy_pass http://backend;
# 连接超时
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
# 失败重试
proxy_next_upstream error timeout http_502 http_503;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
# 请求头传递
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;
}法则17:缓存配置
http {
# 定义缓存路径
proxy_cache_path /var/cache/nginx levels=1:2
keys_zone=api_cache:100m
max_size=10g
inactive=60m
use_temp_path=off;
}
server {
location /api/public/ {
proxy_pass http://backend;
proxy_cache api_cache;
proxy_cache_valid 200 10m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating;
proxy_cache_lock on;
add_header X-Cache-Status $upstream_cache_status;
}
}法则18:安全加固
http {
# 隐藏版本号
server_tokens off;
# 安全响应头
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}
server {
# 禁止访问隐藏文件
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
}法则19:状态监控
server {
listen 127.0.0.1:8080;
location /nginx_status {
stub_status on;
allow 127.0.0.1;
deny all;
}
}法则20:平滑重载
# 检查配置文件语法
nginx -t
# 平滑重载配置
nginx -s reload
# 或者使用systemd
systemctl reload nginx2.3 启动和验证
# 检查配置
nginx -t
# 启动服务
systemctl start nginx
systemctl enable nginx
# 验证运行状态
systemctl status nginx
curl -I http://localhost三、示例代码和配置
3.1 完整配置示例
这是一份经过实战检验的完整配置,适用于10万并发场景:
# /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 1048576;
error_log /var/log/nginx/error.log warn;
pid /run/nginx.pid;
events {
worker_connections 65535;
use epoll;
multi_accept on;
accept_mutex off;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
# 日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'$request_time $upstream_response_time';
log_format json escape=json '{'
'"time":"$time_iso8601",'
'"remote_addr":"$remote_addr",'
'"method":"$request_method",'
'"uri":"$uri",'
'"status":$status,'
'"body_bytes_sent":$body_bytes_sent,'
'"request_time":$request_time,'
'"upstream_response_time":"$upstream_response_time"'
'}';
access_log /var/log/nginx/access.log main buffer=64k flush=5s;
# 基础优化
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
# 超时配置
keepalive_timeout 65;
keepalive_requests 10000;
client_header_timeout 15;
client_body_timeout 15;
send_timeout 15;
# 缓冲区
client_body_buffer_size 128k;
client_max_body_size 100m;
client_header_buffer_size 4k;
large_client_header_buffers 4 32k;
# Gzip压缩
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css text/javascript
application/javascript application/json
application/xml image/svg+xml;
# 文件缓存
open_file_cache max=100000 inactive=60s;
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
# SSL优化
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;
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;
# 限流配置
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
# 代理缓存
proxy_cache_path /var/cache/nginx levels=1:2
keys_zone=api_cache:100m
max_size=10g
inactive=60m
use_temp_path=off;
# 上游服务器
upstream backend {
least_conn;
keepalive 300;
keepalive_requests 10000;
keepalive_timeout 60s;
server 10.0.0.1:8080 weight=3 max_fails=3 fail_timeout=30s;
server 10.0.0.2:8080 weight=3 max_fails=3 fail_timeout=30s;
server 10.0.0.3:8080 weight=2 max_fails=3 fail_timeout=30s;
}
# 虚拟主机配置
include /etc/nginx/conf.d/*.conf;
}3.2 实际应用案例
案例1:电商平台静态资源服务器
背景:日均UV 500万,静态资源请求峰值QPS 5万
server {
listen 80;
listen 443 ssl;
http2 on;
server_name static.example.com;
ssl_certificate /etc/nginx/ssl/static.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/static.example.com.key;
root /data/static;
# 图片资源
location ~* \.(jpg|jpeg|png|gif|webp|ico)$ {
expires 365d;
add_header Cache-Control "public, immutable";
add_header Vary Accept;
access_log off;
# WebP自动转换
set $webp "";
if ($http_accept ~* "webp") {
set $webp ".webp";
}
try_files $uri$webp $uri =404;
}
# CSS/JS资源
location ~* \.(css|js)$ {
expires 30d;
add_header Cache-Control "public, immutable";
access_log off;
}
# 字体资源
location ~* \.(woff|woff2|ttf|eot)$ {
expires 365d;
add_header Cache-Control "public, immutable";
add_header Access-Control-Allow-Origin *;
access_log off;
}
}效果:优化后平均响应时间从15ms降到3ms,带宽使用减少40%(Gzip功劳)。
案例2:API网关配置
背景:微服务架构,需要统一入口,QPS峰值3万
upstream user_service {
least_conn;
keepalive 100;
server 10.0.1.1:8080 max_fails=2 fail_timeout=10s;
server 10.0.1.2:8080 max_fails=2 fail_timeout=10s;
}
upstream order_service {
least_conn;
keepalive 100;
server 10.0.2.1:8080 max_fails=2 fail_timeout=10s;
server 10.0.2.2:8080 max_fails=2 fail_timeout=10s;
}
server {
listen 443 ssl;
http2 on;
server_name api.example.com;
ssl_certificate /etc/nginx/ssl/api.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/api.example.com.key;
# 公共配置
proxy_http_version 1.1;
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 Connection "";
# 用户服务
location /api/v1/users {
limit_req zone=api_limit burst=50 nodelay;
proxy_pass http://user_service;
proxy_connect_timeout 3s;
proxy_read_timeout 30s;
}
# 订单服务
location /api/v1/orders {
limit_req zone=api_limit burst=100 nodelay;
proxy_pass http://order_service;
proxy_connect_timeout 3s;
proxy_read_timeout 60s;
}
# 健康检查
location /health {
access_log off;
return 200 'OK';
add_header Content-Type text/plain;
}
}四、最佳实践和注意事项
4.1 最佳实践
配置分离管理
- 主配置只放全局参数
- 每个虚拟主机独立配置文件
- 使用include指令加载
- 灰度发布配置
split_clients $remote_addr $variant {
10% backend_new;
* backend_old;
}
location /api/ {
proxy_pass http://$variant;
}配置版本控制
- 所有配置纳入Git管理
- 变更前必须review
- 保留回滚版本
监控告警
- 集成Prometheus + Grafana
- 设置QPS、响应时间、错误率告警
- 定期review性能数据
4.2 注意事项
| 常见错误 | 原因分析 | 解决方案 |
|---|---|---|
| worker_connections不生效 | 系统文件描述符限制 | 检查ulimit -n和worker_rlimit_nofile |
| keepalive不生效 | 未设置proxy_http_version和Connection头 | 添加proxy_http_version 1.1和proxy_set_header Connection "" |
| Gzip不生效 | Content-Type未在gzip_types列表中 | 添加对应的MIME类型 |
| SSL握手慢 | 未启用session缓存 | 配置ssl_session_cache |
| 499错误多 | 客户端提前断开 | 检查后端响应时间,调整超时设置 |
| 502/504错误 | 后端超时或不可用 | 检查upstream健康状态,调整超时参数 |
五、故障排查和监控
5.1 故障排查
5.1.1 常用排查命令
# 检查Nginx进程状态
ps aux | grep nginx
# 查看监听端口
ss -tlnp | grep nginx
# 实时查看访问日志
tail -f /var/log/nginx/access.log
# 实时查看错误日志
tail -f /var/log/nginx/error.log
# 查看连接状态统计
ss -s
# 查看TIME_WAIT连接数
ss -ant | grep TIME-WAIT | wc -l
# 测试配置文件
nginx -t
# 查看编译参数
nginx -V5.1.2 性能分析
# 使用wrk进行压力测试
wrk -t12 -c400 -d30s http://localhost/api/test
# 使用ab进行压力测试
ab -n 10000 -c 100 http://localhost/api/test
# 查看nginx_status
curl http://127.0.0.1:8080/nginx_status
# 输出示例:
# Active connections: 2341
# server accepts handled requests
# 12847123 12847123 45123847
# Reading: 12 Writing: 89 Waiting: 22405.2 性能监控
5.2.1 Prometheus集成
# 需要安装nginx-prometheus-exporter
# 配置stub_status后,使用exporter采集数据
server {
listen 127.0.0.1:8080;
location /nginx_status {
stub_status on;
allow 127.0.0.1;
deny all;
}
}Prometheus配置:
scrape_configs:
- job_name: 'nginx'
static_configs:
- targets: ['localhost:9113']5.2.2 关键指标监控
| 指标 | 告警阈值 | 说明 |
|---|---|---|
| nginx_http_requests_total | - | 请求总数,用于计算QPS |
| nginx_connections_active | > 80% worker_connections | 活跃连接数 |
| nginx_connections_waiting | - | 等待连接数 |
| 5xx错误率 | > 1% | 服务端错误 |
| 平均响应时间 | > 500ms | 响应时间 |
| upstream响应时间 | > 1s | 后端响应时间 |
5.3 备份与恢复
# 配置备份脚本
#!/bin/bash
BACKUP_DIR="/data/backup/nginx"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p ${BACKUP_DIR}
tar -czf ${BACKUP_DIR}/nginx_${DATE}.tar.gz /etc/nginx/
# 保留最近30天备份
find ${BACKUP_DIR} -name "*.tar.gz" -mtime +30 -delete
# 恢复命令
tar -xzf ${BACKUP_DIR}/nginx_20250107_120000.tar.gz -C /
nginx -t && systemctl reload nginx六、总结
6.1 技术要点回顾
这20条黄金法则覆盖了Nginx性能调优的方方面面:
- 系统层面:内核参数、文件描述符、CPU亲和性
- Nginx核心:worker进程、连接数、事件模型
- 传输优化:sendfile、TCP优化、keepalive
- 内容优化:Gzip压缩、静态缓存、代理缓存
- 安全防护:限流、超时、安全头
- 监控运维:状态监控、日志分析、平滑重载
实施这些优化后,我见证过的性能提升:
- QPS从1万提升到10万+(10倍)
- 平均响应时间从200ms降到20ms(10倍)
- 服务器资源利用率从80%降到30%(释放了更多资源)
6.2 进阶学习方向
- OpenResty:整合Lua脚本,实现复杂业务逻辑
- Nginx Plus:商业版特性,如主动健康检查、动态配置
- Kubernetes Ingress:云原生场景下的Nginx应用
- 性能极限突破:DPDK、io_uring等新技术
6.3 参考资料
- Nginx官方文档:https://nginx.org/en/docs/
- Nginx性能调优指南:https://nginx.org/en/docs/http/ngx_http_core_module.html
- Linux内核参数详解:https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
附录
A. 命令速查表
| 命令 | 说明 |
|---|---|
nginx -t | 测试配置文件语法 |
nginx -s reload | 平滑重载配置 |
nginx -s stop | 快速停止 |
nginx -s quit | 优雅停止 |
nginx -V | 查看编译参数 |
nginx -T | 输出完整配置 |
B. 配置参数详解
| 参数 | 默认值 | 推荐值 | 说明 |
|---|---|---|---|
| worker_processes | 1 | auto | worker进程数 |
| worker_connections | 512 | 65535 | 单worker最大连接数 |
| keepalive_timeout | 75s | 65s | 客户端keepalive超时 |
| keepalive_requests | 100 | 10000 | 单连接最大请求数 |
| client_max_body_size | 1m | 100m | 请求体最大值 |
| gzip_comp_level | 1 | 5 | Gzip压缩级别 |
C. 术语表
| 术语 | 解释 |
|---|---|
| QPS | Queries Per Second,每秒查询数 |
| TPS | Transactions Per Second,每秒事务数 |
| Keepalive | 持久连接,复用TCP连接 |
| Upstream | 上游服务器,即后端服务 |
| Reverse Proxy | 反向代理 |
| Load Balancing | 负载均衡 |
| epoll | Linux高效的I/O事件通知机制 |
| Zero Copy | 零拷贝技术,减少数据拷贝次数 |
当前页面是本站的「Google AMP」版。查看和发表评论请点击:完整版 »