蒋固金的个人博客
Nginx常用配置以及性能优化
2024-10-22
杂谈
00

目录

第一部分 概述
第二部分 常用配置
2.1 目录结构
2.2 nginx.conf
2.3 siteA.conf
2.4 location配置
2.4.1 基本语法
2.4.2 匹配规则类型
2.4.2.1 精确匹配 (=)
2.4.2.2 前缀匹配 (^~)
2.4.2.3 正则表达式匹配 (~ 和 ~*)
2.4.3. 匹配顺序与优先级
2.4.4 注意事项
第三部分 性能调优
3.1 worker_processes
3.2 worker_connections
3.2.1 含义
3.2.2 配置与计算
3.2.3 具体配置示例
3.3 指定使用的事件模型
3.4 启用Keepalive连接
3.4.1 基本概念
3.4.2 配置项
3.4.2.1 keepalive_timeout
3.5 启用Gzip压缩
3.5.1 基本概念
3.5.2 配置项
3.5.2.1 启用 Gzip
3.5.2.1 主要配置项
3.6 优化缓冲区大小
3.6.1 基本概念
3.6.2 主要配置项
3.6.2.1 clientbodybuffer_size
3.6.2.2 clientmaxbody_size
3.6.2.3 proxybuffersize
3.6.2.4 proxy_buffers
3.6.2.5 proxybusybuffers_size
3.6.3 适用场景
3.7 启用文件缓存
3.7.1 基本概念
3.7.2 主要配置项
3.7.2.1 proxycachepath
3.7.2.2 proxy_cache
3.8 负载均衡
3.8.1 基本概念
3.8.2 主要配置项
3.8.2.1 upstream
3.8.2.3 server块

第一部分 概述

Nginx（发音为“engine x”）是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP代理服务器。Nginx以其轻量级、高并发的特性广泛应用于负载均衡、缓存、静态文件服务和反向代理等场景。

第二部分 常用配置

2.1 目录结构

Nginx的主配置文件通常位于 /etc/nginx/nginx.conf。建议的配置文件目录结构如下：

/etc/nginx/
├── nginx.conf        # 主配置文件
├── conf.d/           # 各站点配置文件
│   ├── default.conf  # 默认配置文件
│   ├── siteA.conf    # 站点A配置文件
│   ├── siteB.conf    # 站点B配置文件
│   └── ...
└── cert/             # SSL证书
    ├── siteA.key     # 站点A私钥
    └── siteA.pem     # 站点A公钥

相关信息

每个站点配置文件中只允许配置该站点下相关规则，禁止将多个站点配置混在一个配置文件中，或将配置全部放在主配置文件nginx.conf中。

2.2 nginx.conf

主配置文件参考内容如下：

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


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"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

相关配置说明如下：

  • user: 指定Nginx工作进程运行的用户。一般建议使用非特权用户（如nginx）来提高安全性。
  • worker_processes: 定义Nginx的工作进程数量。设置为auto时，Nginx会根据CPU核心数自动决定合适的工作进程数。
  • error_log: 指定错误日志文件的路径和日志级别。/var/log/nginx/error.log是日志文件的路径，notice是日志级别，表示记录一般的信息，包括重要的运行状态。
  • pid: 指定Nginx主进程的PID文件路径，通常用于管理Nginx进程（如停止或重新加载配置时）。
  • events: 该块定义与事件处理相关的配置
    • worker_connections: 指定每个工作进程可以同时打开的最大连接数。1024是一个常用的默认值，具体值可根据服务器硬件和需求进行调整。
  • http：该块包含所有HTTP相关的配置。
    • include /etc/nginx/mime.types;：包含MIME类型文件，定义了文件扩展名与MIME类型的对应关系，以便Nginx能正确识别和返回文件类型。
    • default_type application/octet-stream;：如果无法识别请求的文件类型，Nginx将使用application/octet-stream作为默认类型，表示二进制流。
    • log_format main ...：定义访问日志的格式。main是日志格式的名称，后面的字符串定义了记录的内容，如客户端IP、请求时间、请求方法、状态码等。
    • access_log /var/log/nginx/access.log main;：指定访问日志文件的路径，并使用之前定义的main格式记录日志。
    • sendfile on;：启用高效的文件传输，减少数据在内核空间和用户空间之间的复制，提高静态文件的传输效率。
    • keepalive_timeout 65;：设置客户端与服务器之间的连接保持活动的时间。连接在65秒内未被关闭，将被自动关闭，有助于节省资源。
    • #gzip on;：此行被注释掉了，表示未启用Gzip压缩。启用后可以减少传输的数据量，提高网页加载速度。
    • include /etc/nginx/conf.d/*.conf;：包含/etc/nginx/conf.d/目录下的所有配置文件。这使得用户可以将不同的虚拟主机或服务配置分散到多个文件中，便于管理和维护。

2.3 siteA.conf

此部分仅供参考，建议以实际站点名称进行配置文件命名

server {
    listen 443 ssl;
    server_name  siteA;
    ssl_certificate /etc/nginx/cert/siteA.pem;
    ssl_certificate_key /etc/nginx/cert/siteA.key;
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass   http://ip:port;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarder-For $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
    }
}
server {
    listen       80;
    server_name  siteA;

    # 将所有HTTP请求通过rewrite指令重定向到HTTPS。
    rewrite ^(.*)$ https://$host$1;
    location / {
        index index.html index.htm;
    }
}

2.4 location配置

在 Nginx 中，location 指令用于定义请求路径的匹配规则，它可以根据请求的 URI 将请求转发到不同的后端服务器或执行不同的处理逻辑。Nginx 提供了多种匹配方式，可以精确或模糊匹配请求路径。了解 location 的匹配规则有助于优化 Nginx 的配置，以实现高效的路由处理。

2.4.1 基本语法

location [匹配模式] [URI] {
    # 配置指令
}
  • 匹配模式：定义如何匹配请求路径，包括精确匹配、前缀匹配、正则匹配等。
  • URI：请求路径部分，用于确定匹配规则。

2.4.2 匹配规则类型

Nginx 中的 location 匹配方式大致可以分为三类：精确匹配、前缀匹配和正则表达式匹配。这些匹配方式的顺序和优先级很重要，因为 Nginx 会按照优先级依次检查每个 location，并选择最合适的一个。

2.4.2.1 精确匹配 (=)

  • 描述：当 location 以 = 开头时，表示进行精确匹配。如果请求的 URI 与指定的 URI 完全相同，则匹配此 location。

  • 优先级：最高。

  • 示例：

    location = / {
    # 精确匹配根路径 /
}

  • 适用场景：通常用于处理根路径或特定的单一请求。

2.4.2.2 前缀匹配 (^~)

  • 描述：当 location 以 ^~ 开头时，表示前缀匹配，并且一旦匹配成功，就不再检查正则表达式匹配的 location。

  • 优先级：比正则表达式匹配高。

  • 示例：

    location ^~ /static/ {
    # 匹配以 /static/ 开头的路径，忽略正则匹配
}

  • 适用场景：适用于静态资源文件夹、图片、CSS、JS 等路径。

2.4.2.3 正则表达式匹配 (~ 和 ~*)

  • 描述：~ 用于区分大小写的正则表达式匹配，~* 用于不区分大小写的正则表达式匹配。正则表达式匹配的优先级最低，但如果没有匹配到更高优先级的 location，Nginx 将尝试匹配正则表达式。

  • 优先级：低于精确匹配和前缀匹配。

  • 示例：

    location ~ \.php$ {
    # 匹配所有以 .php 结尾的路径，区分大小写
}

location ~* \.(jpg|jpeg|png|gif)$ {
    # 匹配所有以 .jpg、.jpeg、.png、.gif 结尾的路径，不区分大小写
}

  • 适用场景：适用于需要正则匹配的场景，如根据文件扩展名区分不同类型的请求。

2.4.3. 匹配顺序与优先级

Nginx 按照以下顺序来匹配 location 指令：

  1. 精确匹配 (=)：最先检查的，优先级最高。
  2. 前缀匹配 (^~)：优先级次之，如果匹配成功，Nginx 不会再继续匹配正则表达式。
  3. 正则表达式匹配 (~ 和 ~*)：最后检查，如果前面都没有匹配成功，则进行正则表达式匹配。
  4. 默认匹配：如果没有任何匹配，Nginx 会选择常规前缀匹配(没有特殊符号的 location 是常规的前缀匹配)中最长的那个。

2.4.4 注意事项

  • 优先级问题：如果多个 location 块都匹配相同的 URI，Nginx 会根据优先级选择最合适的一个。因此，建议先定义优先级较高的规则，如 = 和 ^~，然后定义常规的匹配。
  • 正则匹配的性能：正则表达式匹配在性能上可能不如前缀匹配高效，因此在可能的情况下，优先使用前缀匹配。
  • 避免模糊匹配：在复杂的路由规则中，尽量避免过多的模糊匹配，以减少调试难度和提升效率。

第三部分 性能调优

3.1 worker_processes

worker_processes定义Nginx的工作进程数量。设置为auto时，Nginx会根据CPU核心数自动决定合适的工作进程数。

  • 设置为auto
    • 动态调整：Nginx会自动检测服务器的CPU核心数，并相应地设置工作进程的数量，通常会设置为CPU核心数的数量。
    • 资源利用优化：在多核CPU上，auto可以充分利用所有核心，提高并发处理能力，特别适合高流量环境。
    • 简化配置：用户无需手动计算和调整进程数，配置更简单。
  • 设置为固定值
    • 固定进程数：用户手动指定工作进程的数量，这可能会导致资源利用不均。
    • 适应特定环境：在某些情况下，如资源受限的环境或特殊需求，可能需要固定的进程数以控制资源使用。
    • 可能造成瓶颈：如果设置的进程数少于CPU核心数，可能无法充分利用系统资源，导致性能瓶颈。

在无法确定或没有特殊要求的情况下，该值通常设置为auto以发挥Nginx的最大性能。

3.2 worker_connections

worker_connections是Nginx中用于定义每个工作进程能够同时打开的最大连接数的配置项。合理配置这个参数对于提高服务器的并发处理能力至关重要。

3.2.1 含义

  • 并发连接：worker_connections指定的是每个Nginx工作进程可以同时处理的连接数，包括来自客户端的连接和与后端服务器（如数据库或应用服务器）的连接。
  • 总连接数：Nginx能够处理的总连接数等于worker_processes乘以worker_connections，即：总连接数 = worker_processes × worker_connections

3.2.2 配置与计算

  1. 确定服务器的负载需求：根据网站的访问量和并发用户数估算所需的连接数。例如，如果预计同时在线用户数为1000，并且每个用户打开多个连接（如长连接、HTTP/2等），需要的连接数可能会更高。

  2. 评估服务器资源：了解服务器的硬件配置，包括CPU核心数、内存和网络带宽。确保服务器能够承受所配置的连接数。

  3. 选择合适的worker_processes值：通常可以设置为CPU核心数的数量或其倍数，以确保充分利用CPU资源。

  4. 配置worker_connections：根据需要的并发连接数和worker_processes来设置。例如，如果设置了4个工作进程，预计的总连接数为4000，那么每个进程的连接数应设置为1000：

    worker_connections = 总连接数 / worker_processes = 4000 / 4 = 1000

3.2.3 具体配置示例

假设有以下情况：

  • 服务器有4个CPU核心。
  • 预计同时在线用户数为2000。
  • 每个用户平均打开3个连接。

计算：

  • 需要的总连接数：2000用户 × 3连接/用户 = 6000连接。
  • 设置worker_processes为4（CPU核心数）。
  • 根据上述公式，计算worker_connections：worker_connections = 6000 / 4 = 1500

配置示例：

worker_processes 4;
events {
    worker_connections 1500;
}

3.3 指定使用的事件模型

根据操作系统的不同，Nginx 支持多种事件处理机制，如 select、poll、epoll、kqueue 等。

常用事件模型：

  • select：适用于小型应用，性能较低，支持的连接数有限。
  • poll：比 select 更高效，但在连接数增加时性能下降。
  • epoll：仅在 Linux 下可用，支持大量并发连接，性能优秀。
  • kqueue：适用于 FreeBSD 和 MacOS 系统，支持高并发。

配置示例：

events {
    use epoll;  # 在 Linux 系统上使用 epoll 事件模型
}

3.4 启用Keepalive连接

keepalive 是 Nginx 中用于保持客户端与服务器之间持久连接的功能。通过使用 keepalive，可以减少连接建立和关闭的开销，从而提高性能。

3.4.1 基本概念

  • 持久连接：keepalive 允许在同一 TCP 连接上发送多个 HTTP 请求，避免每个请求都重新建立连接。
  • 性能优化：通过减少握手次数，keepalive 可以显著提高响应速度和降低延迟，尤其在高并发环境中。

3.4.2 配置项

3.4.2.1 keepalive_timeout

  • 含义：指定服务器在客户端没有发送请求的情况下，保持连接的最大时间（以秒为单位）。

  • 示例：

    server {
    listen 80;
    server_name example.com;

    keepalive_timeout 65;  # 设置保持连接超时时间为65秒
}

3.4.2.2 keepalive_requests

  • 含义：指定每个持久连接允许的最大请求数。达到该请求数后，连接将被关闭。

  • 示例：

    server {
    listen 80;
    server_name example.com;

    keepalive_requests 100;  # 每个连接最大允许100个请求
}

3.4.3 适用场景

  • 高并发应用: 在高并发环境中，keepalive 可以减少连接建立的开销，提高请求处理效率。
  • API 服务: 对于提供 API 的服务，keepalive 可以提高请求的响应速度，尤其是在短时间内发送多个请求的情况下，保持连接可以降低延迟。
  • 静态文件服务: 在静态文件服务中（如图片、CSS、JS 文件），使用 keepalive 可以减少每次请求时的延迟，提高文件加载速度。

注意

过长的 keepalive_timeout 可能会导致服务器资源浪费，尤其是在低流量环境中。

3.5 启用Gzip压缩

Gzip 是一种常用的压缩技术，能够显著减少 HTTP 响应数据的大小，从而加快页面加载速度和降低带宽使用。

3.5.1 基本概念

  • 压缩机制：Gzip 会对服务器发送到客户端的响应数据进行压缩，客户端接收到数据后再解压缩。这样可以减少数据传输的大小，提高加载速度。

3.5.2 配置项

3.5.2.1 启用 Gzip

要启用 Gzip 压缩，需要在 Nginx 配置文件的 http 块中添加以下配置：

http {
    gzip on;  # 启用 Gzip 压缩
}

3.5.2.1 主要配置项

  • gzip_types：指定哪些 MIME 类型的响应数据将被压缩。默认情况下，只有文本文件类型（如 HTML、CSS、JavaScript 等）会被压缩。

    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  • gzip_min_length：设置压缩的响应数据的最小长度，只有大于该长度的响应才会被压缩。可以减少小文件的处理开销。

    gzip_min_length 1000;  # 仅压缩大于1000字节的响应

  • gzip_comp_level：设置压缩级别，范围从 1 到 9。级别越高，压缩率越高，但 CPU 使用率也会增加。通常建议设置为 5。

    gzip_comp_level 5;  # 设置压缩级别为5

  • gzip_vary：启用 Vary: Accept-Encoding 头，允许不同的客户端（支持 Gzip 的和不支持的）接收不同的响应，从而实现更好的缓存效果。

    gzip_vary on;  # 启用 Vary 头

  • gzip_disable：用于指定不启用 Gzip 压缩的条件。例如，可以根据用户代理（User-Agent）禁用 Gzip。

    gzip_disable "MSIE [1-6]\.";  # 禁用 IE 6 及以下版本的 Gzip

3.5.3 适用场景

  • 高流量网站: 对于高流量的网站，Gzip 能有效减少带宽消耗，降低服务器负担，加快用户的页面加载速度。
  • 静态资源: 在提供静态资源（如 CSS、JavaScript 和图片等）时，Gzip 可以大幅度压缩这些文件，提高加载效率。
  • API 服务: 对于返回 JSON 数据的 API 服务，使用 Gzip 压缩可以减少响应数据的大小，提高数据传输的效率。

注意

启用 Gzip 压缩会增加 CPU 使用率，尤其是在压缩级别较高时。应根据服务器性能进行调整。

3.6 优化缓冲区大小

在 Nginx 中，缓冲区大小的配置是影响性能和响应速度的重要因素，特别是在处理大文件和高并发请求时。合理配置缓冲区可以优化资源使用，提升用户体验。

3.6.1 基本概念

缓冲区用于临时存储传入和传出的数据，以减少磁盘 I/O 和网络延迟。Nginx 提供多个缓冲区配置选项，主要用于控制请求和响应的数据处理。

3.6.2 主要配置项

3.6.2.1 client_body_buffer_size

  • 含义：指定 Nginx 用于存储客户端请求体的缓冲区大小。对于 POST 请求，Nginx 会将请求体存储在该缓冲区中。

  • 示例：

    http {
    client_body_buffer_size 16k;  # 设置为16KB
}

  • 适用场景：适用于接收较大的 POST 请求（如文件上传）时，增加该值可以减少磁盘 I/O。

3.6.2.2 client_max_body_size

  • 含义：限制客户端请求体的最大大小。如果请求体超过该限制，Nginx 会返回 413 错误。

  • 示例：

    http {
    client_max_body_size 20m;  # 最大请求体为20MB
}

  • 适用场景：主要用于控制文件上传的大小，防止恶意用户上传过大的文件。

3.6.2.3 proxy_buffer_size

  • 含义：指定用于存储从后端服务器接收的响应头的缓冲区大小。

  • 示例：

    http {
    proxy_buffer_size 8k;  # 设置为8KB
}

  • 适用场景：适用于需要处理大响应头的 API 或后端服务。

3.6.2.4 proxy_buffers

  • 含义：设置用于存储从后端服务器接收的响应数据的缓冲区数量和大小。

  • 示例：

    http {
    proxy_buffers 4 16k;  # 使用4个16KB的缓冲区
}

  • 适用场景：适用于需要高并发和大响应体的场景，如视频流服务和大文件下载。

3.6.2.5 proxy_busy_buffers_size

  • 含义：指定在处理请求时，正在使用的缓冲区的最大大小。

  • 示例：

    http {
    proxy_busy_buffers_size 32k;  # 设置为32KB
}

  • 适用场景：当后端响应较慢时，增加该值可以防止缓冲区过早地被写入磁盘。

3.6.3 适用场景

  • 高并发应用：在处理大量并发请求时，合理设置缓冲区可以提高响应速度，减少磁盘 I/O。
  • 大文件传输：在进行文件上传或下载时，增加 client_body_buffer_size 和 proxy_buffers 可以优化性能。
  • API 服务：在 API 服务中，设置合适的缓冲区可以处理大响应体，提高客户端的接收效率。

注意

缓冲区的大小直接影响服务器的内存使用，应根据服务器资源合理配置。

3.7 启用文件缓存

在 Nginx 中，文件缓存是一种优化技术，可以显著提高静态文件的传输速度和减少后端服务器的负载。通过将静态文件的响应缓存到本地存储，Nginx 可以在后续请求中快速响应，而无需每次都从后端获取数据。

3.7.1 基本概念

文件缓存允许 Nginx 将特定类型的响应数据（通常是静态文件）存储在本地，以便在后续请求中快速提供这些数据。这可以减少后端服务器的负载，提高用户的访问速度。

3.7.2 主要配置项

3.7.2.1 proxy_cache_path

  • 含义：定义缓存路径、缓存键和缓存参数。

  • 示例：

    http {
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
}

  • 参数说明：

    • /var/cache/nginx：缓存文件的存储路径。
    • levels=1:2：定义目录层次结构（如 1 表示一级目录，2 表示二级目录），可优化文件系统性能。
    • keys_zone=my_cache:10m：定义缓存区域的名称和大小，这里是 10MB。
    • max_size=1g：最大缓存大小为 1GB。
    • inactive=60m：在 60 分钟内未被访问的缓存项会被自动删除。
    • use_temp_path=off：禁用临时路径，直接在目标缓存路径中存储。

3.7.2.2 proxy_cache

  • 含义：在特定的 location 块中启用缓存。

  • 示例：

    location /api/ {
    proxy_pass http://backend;
    proxy_cache my_cache;  # 启用之前定义的缓存区域
}

3.7.2.3 proxy_cache_key

  • 含义：自定义缓存键，可以通过变量构建缓存键。

  • 示例：

    location / {
    proxy_cache my_cache;
    proxy_cache_key "$scheme$request_method$host$request_uri";
}

3.7.2.4 proxy_cache_valid

  • 含义：设置缓存的有效时间，不同状态码的缓存时间可以不同。

  • 示例：

    location / {
    proxy_cache my_cache;
    proxy_cache_valid 200 1h;  # 200 响应缓存 1 小时
    proxy_cache_valid 404 10m;  # 404 响应缓存 10 分钟
}

3.7.3 适用场景

  • 高流量网站: 对于高流量的静态网站，使用文件缓存可以显著提高响应速度，减少服务器负载。
  • API 服务: 在 API 服务中，缓存常见的请求和响应可以减少后端负担，提升响应效率。
  • 静态资源: 对于 CSS、JavaScript 和图片等静态资源，通过缓存可以加快加载速度，提高用户体验。

注意

确保合理设置缓存有效时间，以避免过期数据的使用。

3.8 负载均衡

在 Nginx 中，负载均衡是一种将请求分发到多个后端服务器的技术，旨在提高应用的可用性和响应速度。通过合理配置负载均衡，Nginx 可以有效地管理服务器资源，确保高并发情况下的稳定性。

3.8.1 基本概念

负载均衡可以将用户的请求分发到多个后端服务器，以实现更好的资源利用和故障转移。Nginx 支持多种负载均衡算法，可以根据具体需求选择适合的方式。

3.8.2 主要配置项

3.8.2.1 upstream

  • 含义：定义后端服务器组。所有负载均衡的配置都在此块中进行。

  • 示例：

    upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

3.8.2.2 负载均衡算法

Nginx 支持多种负载均衡算法，以下是几种常用的：

  • 轮询（默认）：每个请求按顺序分配到后端服务器。
upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
  • 最少连接：将请求发送到当前连接数最少的服务器。
upstream backend {
    least_conn;  # 使用最少连接算法
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

IP 哈希：根据客户端 IP 地址的哈希值将请求分配到固定的后端服务器。

upstream backend {
    ip_hash;  # 使用 IP 哈希算法
    server backend1.example.com;
    server backend2.example.com;
}

3.8.2.3 server块

在 server 块中使用 proxy_pass 将请求转发到定义的 upstream 服务器组。

  • 示例：

    server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;  # 转发请求到 upstream 定义的后端服务器
    }
}

注意

对于需要会话保持的应用，可以使用 sticky 或 ip_hash 方法，以确保用户的请求始终被发送到同一台服务器。

如果对你有用的话，可以打赏哦
打赏
ali pay
wechat pay

本文作者:蒋固金

本文链接:

版权声明:本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！