这篇文章不打算从“什么是 Nginx”讲起，直接讲实战。目标也很明确：让 Spring Boot 跑在 Nginx 后面时，页面能正常访问、接口不容易超时、大文件上传能过、真实客户端 IP 能拿到，遇到问题时也知道该先看哪一层。

一、先说结论：Nginx 不是摆设，是边界

把 Nginx 放在前面，最直接的好处有三个：一是做统一入口，二是接管静态资源和 HTTPS，三是把后端服务从外网直接暴露的状态里拉回来。说白了，Nginx 不是单纯“转发请求”的工具，它更像一个门卫：先看流量怎么进来，再决定哪些请求放给 Spring Boot，哪些请求直接在前面就处理掉。

如果你一开始就把责任全推给 Spring Boot，后面会很痛。比如静态文件明明能由 Nginx 直接返回，却硬要打到后端；再比如前端上传一个 20MB 文件，Nginx 默认限制不够，直接 413；或者用户访问日志里全是 127.0.0.1，真实客户端 IP 丢了，排查起来很麻烦。

二、最常见的一套基础配置

先上一个比较稳的基础版。你不用一次性把所有功能都塞进去，先让核心链路跑通，再逐项补强，通常更省事。

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host ;
        proxy_set_header X-Real-IP ;
        proxy_set_header X-Forwarded-For ;
        proxy_set_header X-Forwarded-Proto ;
    }
}

这几行里，最关键的是 proxy_set_header。很多“看起来能访问，但日志不对”的问题，根子都在这里。

• Host：把原始域名传给后端，避免 Spring Boot 看到的是内部地址。
• X-Real-IP：把直连客户端 IP 带过去。
• X-Forwarded-For：保留完整代理链，排查时很有用。
• X-Forwarded-Proto：告诉后端当前是 http 还是 https，做跳转和生成链接时很重要。

三、502 大多不是“挂了”，而是超时或连接方式不对

很多人一看到 502 就下意识以为后端服务崩了。其实不一定。更常见的是三种情况：后端没起来、Nginx 连不上、或者 Nginx 等得不耐烦了。

先看 Nginx 日志，再看 Spring Boot 日志，这个顺序别反。因为 Nginx 先感知到失败，它会留下更直观的错误，比如 connect() failed、upstream timed out、no live upstreams 之类的信息。后端日志则更像“事情发生前后”的补充材料。

我一般会优先检查这几个点：

1. Spring Boot 是否真的监听在 8080 或其他端口上。
2. Nginx 的 proxy_pass 是否写对了协议和端口。
3. 防火墙和安全组有没有拦截本机或内网访问。
4. 接口是不是本身太慢，导致代理层超时。

超时配置别太保守

Spring Boot 后面如果有数据库查询、远程接口调用、导出文件这种慢操作，默认超时往往不够。Nginx 可以适当加长：

location /api/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_connect_timeout 10s;
    proxy_read_timeout 60s;
    proxy_send_timeout 60s;
    send_timeout 60s;
}

这几个超时不要乱加到特别大。大不是好事，太大了，真卡住的时候用户会等很久。我的习惯是：先把链路跑通，再根据接口类型单独设置。查询类接口和导出类接口，不该用同一个超时值。

四、大文件上传：413 和空白上传页通常是 Nginx 先拦了

Spring Boot 的上传接口本身没问题，但 Nginx 默认的请求体大小限制可能先把你挡住。最常见的表现就是前端一直转圈，或者直接报 413 Request Entity Too Large。

这个时候别先怀疑后端。先把 Nginx 的限制打开：

server {
    client_max_body_size 50m;

    location /upload/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_request_buffering off;
        proxy_read_timeout 120s;
    }
}

client_max_body_size 是第一道门。proxy_request_buffering off 则在某些上传场景里很有用，尤其是你想让请求尽快流向后端处理时。至于具体要不要关缓冲，得看业务类型，不是所有场景都适合。

如果你后台有图片、视频、导入文件这些功能，建议把上传接口单独拆个 location，别跟普通 API 混在一起。上传和查询本来就是两种流量，不能按一个模板配到底。

五、真实客户端 IP 一定要保住

这个问题看起来不大，但一旦你做审计、风控、限流、登录保护，就会非常在意。Spring Boot 如果直接拿到的是 Nginx 的内网地址，很多记录就失真了。

前面 Nginx 已经传了 X-Forwarded-For，后端也要正确识别它。Spring Boot 如果用了 Tomcat，可以考虑加上对转发头的支持；如果是 Spring Security、审计日志、接口限流，也要确认读取的是转发后的真实 IP，不是默认的 request.getRemoteAddr()。

这一步常常被忽略。等你哪天发现某个账号异常登录，全都记录成 127.0.0.1 或者内网地址，才会意识到之前少做了什么。

六、HTTPS 放在 Nginx 上更省心

证书、加密、重定向这些事，放在 Nginx 上一般更清楚。后端只管业务，外层负责 HTTPS 终止，这样 Spring Boot 的配置会干净很多。

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/nginx/cert/fullchain.pem;
    ssl_certificate_key /etc/nginx/cert/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host ;
        proxy_set_header X-Forwarded-Proto https;
    }
}

如果你还保留 80 端口，建议直接跳转到 https，别让用户手动猜。

server {
    listen 80;
    server_name example.com;
    return 301 https://;
}

七、静态资源别浪费后端资源

如果你的项目里有图片、JS、CSS、字体这些静态文件，能让 Nginx 直接处理就尽量直接处理。Spring Boot 不是不能干这件事，只是它不该把时间花在这种重复工作上。

静态资源走 Nginx 后，响应更快，后端连接数也更轻松。尤其是首页、管理后台、活动页这种资源比较多的地方，差别很明显。

八、排障时我会先看这四样

遇到问题时，我通常不会马上改配置，而是先看四个点：

• Nginx error.log
• Nginx access.log
• Spring Boot 应用日志
• curl 直接访问后端端口的结果

这个顺序很土，但很管用。因为很多问题不是配置本身错了，而是你压根不知道失败发生在哪一层。curl 一下后端，如果直连没问题，那就回头看 Nginx；如果直连都失败，那就别在代理层上绕太久。

九、给一个可以直接抄的稳妥版本

server {
    listen 80;
    server_name example.com;
    return 301 https://;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    client_max_body_size 50m;

    ssl_certificate     /etc/nginx/cert/fullchain.pem;
    ssl_certificate_key /etc/nginx/cert/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host ;
        proxy_set_header X-Real-IP ;
        proxy_set_header X-Forwarded-For ;
        proxy_set_header X-Forwarded-Proto https;
        proxy_connect_timeout 10s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }
}

这套配置不花哨，但足够稳。先把访问、转发、证书、上传这几件事跑通，再去细分图片、下载、接口限流、缓存这些更细的模块。

反向代理这件事，真的不是把请求“转过去”那么简单。你越早把边界、超时、头信息、上传限制这些点想清楚，后面越少半夜改配置。系统能稳定跑，通常不是因为某一条配置很神，而是每一个小地方都没偷懒。

我后来处理这类问题的思路很简单：先分清是“查不到数据”还是“热点数据扛不住”，再看是不是“很多 key 一起过期了”或者“Redis 自己先不稳定”。这几个点分开看，处理办法其实不一样。

一、先把三个概念说清楚

缓存穿透，指的是请求的数据在缓存里没有，在数据库里也没有。比如有人一直拿一个不存在的 id 去查，缓存 miss，数据库也 miss，每次都穿过缓存打到数据库，量一大，数据库会被白白消耗。

缓存击穿，通常是某个热点 key 突然过期了，恰好这个 key 又特别热。过期那一瞬间，大量请求一起打到数据库，像在缓存上开了一个洞。

缓存雪崩，是更大范围的问题。大量 key 在同一时间失效，或者 Redis 整个服务挂了，结果原本应该被缓存挡住的流量，成片地落到数据库上。

这三种问题看上去都像“Redis 不工作了”，但真正的处理方式差别很大。穿透要防无效请求，击穿要防热点失守，雪崩要防批量失效和整站级联。

二、缓存穿透：最常见，也最容易被忽略

穿透一般不是 Redis 的错，而是系统没有拦住那些本来就不该继续往下走的请求。比如用户输入错误、爬虫扫描、恶意探测，甚至是前端参数没校验好，都会把不存在的 id 发给后端。

线上真出问题时，你会看到几个很典型的信号：缓存命中率明显下降，数据库的简单查询骤增，而且这些查询返回的结果几乎都是空。更麻烦的是，这种流量看起来“不重”，但因为全是无效请求，完全是在浪费资源。

我一般会先上这三层防线：

• 参数校验，先把明显非法的请求挡在最前面。
• 缓存空值，对短时间内重复查不到的数据做一个短 TTL 的空对象缓存。
• 布隆过滤器，把明显不存在的数据直接拦掉。

1. 参数校验先做掉

这一步听起来很普通，但它的性价比其实最高。比如用户 id、商品 id、文章 id 这些字段，很多场景下本来就有范围限制。你在进入缓存之前做一次校验，能省掉不少无意义的查库。

// 伪代码
if (id <= 0) {
    return null;
}
if (id > MAX_ID) {
    return null;
}

别小看这个动作。很多系统真正的穿透，不是攻击很强，而是前面的入口太松。

2. 空值缓存要有，但 TTL 不能太长

如果某个 key 查不到，你可以把一个空值缓存起来，比如缓存 30 秒到 2 分钟。这样同一个不存在的请求短时间内不会反复打数据库。

但空值缓存不是越久越好。时间太长，会让新数据创建后迟迟看不到。这个问题我见过不少次：为了防穿透，把空对象缓存了半小时，结果用户刚新建的内容，页面还一直显示不存在。

所以我更倾向于短 TTL + 适当随机抖动。对不存在的数据，缓存时间短一点够用，别让它变成另一个一致性问题。

3. 布隆过滤器适合挡大批量无效请求

如果你的数据量比较大，或者外部请求很杂，布隆过滤器会比单纯的空值缓存更稳一些。它的思路是：先把“可能存在”的 id 放进过滤器里，查不到的直接拒绝。

它的缺点也要认：有一定误判率，也就是会把少量本来存在的数据误判成不存在。所以它更适合做前置拦截，不适合单独承担最终判断。

三、缓存击穿：热点 key 到点失守

击穿和穿透最大的区别，在于这里的数据本来是存在的。只是缓存到期了，热门请求又刚好集中到这个 key 上。于是缓存层空了，数据库突然被推上前台。

这类问题最典型的场景，就是首页推荐、秒杀库存、热门商品详情、活动配置页。只要某个 key 足够热，一过期就会有人一起去重建缓存。

我见过一种特别常见的写法：缓存过期后，第一个请求去查数据库并重建缓存，其他请求直接放过去。这个逻辑看上去没错，但在高并发下很容易炸，因为第一个请求还没来得及写回缓存，后面一批请求已经同时打到数据库了。

解决击穿，通常有两条路：互斥锁 和 逻辑过期。

1. 互斥锁：简单直接，适合大多数场景

思路就是：缓存 miss 之后，先抢锁，抢到的人去查数据库并回填缓存；没抢到的人先等一下，再重新读缓存。这样可以避免大家一起冲进数据库。

// 伪代码
String key = product:1001;
String value = redis.get(key);
if (value != null) return value;

boolean locked = tryLock(lock:product:1001);
if (!locked) {
    sleep(50);
    return redis.get(key);
}
try {
    value = db.queryProduct(1001);
    redis.set(key, value, 300, TimeUnit.SECONDS);
    return value;
} finally {
    unlock(lock:product:1001);
}

这个方案的优点是直观，缺点也很明显：高峰期会有一批请求排队，延迟会上升。不过比数据库直接被打穿要好得多。

2. 逻辑过期：更适合热点很高的读多写少数据

逻辑过期的做法更像“先继续用旧数据，再后台更新”。缓存里不直接存业务对象，而是存一个对象和一个过期时间。请求进来时，如果发现逻辑过期，就先返回旧数据，同时异步刷新缓存。

这个办法的好处是，用户几乎感受不到抖动。坏处是实现复杂一点，而且你得接受短时间内返回旧值。

// 伪代码
class CacheData {
    Object data;
    long expireAt;
}

CacheData cache = redis.get(key);
if (cache != null && cache.expireAt > System.currentTimeMillis()) {
    return cache.data;
}

if (cache != null && tryLock(lock: + key)) {
    asyncReload(key);
    return cache.data;
}

如果你问我怎么选：普通业务优先互斥锁，特别热的读多写少场景再考虑逻辑过期。别一上来就把方案做得很重，没必要。

四、缓存雪崩：真正危险的是“同时失效”

雪崩比击穿更麻烦，因为它不是一个点，而是一片。常见原因有两个：一是很多 key 设置了相同或接近的过期时间，二是 Redis 自己出问题，导致缓存层整体失效。

如果大量 key 同一秒过期，数据库就像突然少了一层缓冲；如果 Redis 整个挂掉，情况更直接，所有请求都会往下游走。这个时候，数据库、接口线程池、连接池，任何一个地方都可能先顶不住。

1. 给 TTL 加随机抖动

这是最实用的一招。别让 key 在同一个整点失效，TTL 可以加一点随机值，比如基础 10 分钟，再加 0 到 5 分钟随机时间。

// 伪代码
int baseTtl = 600;
int randomExtra = new Random().nextInt(300);
redis.set(key, value, baseTtl + randomExtra, TimeUnit.SECONDS);

这一点很朴素，但真的能救命。很多雪崩不是系统设计很差，而是大家习惯了把 TTL 写得整整齐齐。

2. 热点数据分层，别把鸡蛋放一个篮子里

如果业务很重，建议做多级缓存：本地缓存 + Redis + 数据库。这样就算 Redis 抖一下，本地缓存还能顶住一部分请求。热门配置、基础字典、活动信息这类内容，尤其适合这么做。

不过多级缓存不是白送的，数据一致性会复杂一些。你得明确哪些数据可以短时间不一致，哪些数据必须实时更新。别什么都塞进去，最后把自己绕晕。

3. Redis 真挂了，也要有降级策略

很多系统平时一直盯着缓存命中率，却忘了 Redis 真的挂了以后怎么办。比较稳的做法是：在网关、服务层或者中间件层提前准备降级逻辑。比如直接返回默认数据、关闭非核心功能、把写请求打到消息队列里缓慢恢复。

如果你没有降级，雪崩就不只是数据库压力大，而是整条链路一起倒。

五、我常用的一套生产处理顺序

这几年碰过几次缓存事故后，我自己慢慢形成了一套固定顺序：

1. 先确认是穿透、击穿还是雪崩，不要一上来就重构。
2. 先补入口校验，再看空值缓存和布隆过滤器。
3. 热点 key 用互斥锁，特别热的读多写少数据再考虑逻辑过期。
4. TTL 不要整齐划一，必须加随机抖动。
5. 核心数据准备降级和兜底，别把 Redis 当成唯一防线。

很多线上问题不是技术难，而是顺序乱。你如果先想着“要不要上布隆过滤器”，却连最基本的参数校验都没做好，系统会绕很多弯。

六、几个容易踩的坑

第一个坑：空值缓存时间太长。为了省一次查库，把不存在的数据缓存太久，结果业务数据新增后迟迟不刷新。

第二个坑：锁写得不严。抢锁失败后直接重试，没有退避，最后变成大量线程空转。

第三个坑：把所有 key 的 TTL 都写成一样。测试环境看不出来，真实流量一波过去，问题集中爆发。

第四个坑：只做缓存，不做降级。Redis 正常时一切都好看，Redis 一旦波动，整套系统没有第二方案。

七、给一个可以直接落地的判断标准

如果你现在就要开始改，我建议先按下面这个标准做：

• 对不存在的数据，先做参数校验，再考虑空值缓存。
• 对高频热点数据，先加互斥锁，不要让很多请求一起查库。
• 对大批量缓存 key，TTL 一定加随机值。
• 对核心链路，准备降级方案。

这样做不花哨，但基本能把 Redis 相关的三类常见事故压住。等系统真的稳定下来，再去考虑更复杂的多级缓存、异步重建、热点探测这些东西。

说到底，缓存这件事不是炫技。最有价值的，通常是把每一层防线都补到位。只要入口、缓存、数据库之间的边界清楚了，很多看似复杂的问题，其实会安静很多。

说起Linux 服务器安全加固的 10 个细节，这还真是我这两年踩坑最多、但也最受益的一个技术领域了。今天这篇文章不整那些虚头巴脑的理论，直接把我这几年在实战中总结的干货、踩过的坑、验证过的方案，一次性全掏出来给你。文章有点长，但保证每一段都是精华，建议先收藏再看。

我见过太多团队，前期为了赶进度，在配置上偷工减料，结果系统上线后问题频发：性能瓶颈、安全漏洞、数据不一致... 最后花了几倍的时间去填坑。所以这篇文章的目的，就是帮你避开这些坑，一次性把Linux 服务器安全加固的 10 个细节搞明白。

二、实战前的准备工作

在动手之前，有些基础工作必须做好。别急着写代码，先花 10 分钟检查一下环境。

2.1 环境要求

• 操作系统：推荐 Linux (CentOS 7+ / Ubuntu 20.04+)
• 内存：至少 2GB（生产环境建议 4GB+）
• 磁盘：预留足够空间，建议 20GB 起

2.2 依赖安装

# 以 Ubuntu 为例
sudo apt update
sudo apt install -y curl wget git vim
# 安装核心组件
# ...具体依赖根据主题而定

这里有个坑要提醒大家：有些依赖包版本不兼容，一定要按照官方文档来，别自己瞎搞。我之前就因为版本问题，折腾了一整天。

三、核心实施步骤（重点）

好，环境准备好了，咱们进入正题。下面是Linux 服务器安全加固的 10 个细节的完整实施流程，我会把每一步的操作、原理、注意事项都讲清楚。

3.1 第一步：基础配置

这一步的目标是搭建最小可用环境。别小看这一步，很多后期问题都是基础配置不当埋下的隐患。

# 示例配置
config {
    key1: value1;
    key2: value2;
    # 关键参数，根据实际需求调整
    max_connections: 1024;
    timeout: 30s;
}

关键点说明：

• max_connections：最大连接数，根据服务器性能调整，别盲目设大
• timeout：超时时间，太短容易误判，太长影响资源回收

3.2 第二步：核心参数优化

默认配置只能保证"能用"，但要"好用"，必须优化。下面是我压测了无数次得出的最佳参数组合：

# 性能优化配置
performance {
    buffer_size: 4096;
    worker_processes: auto;
    keepalive_timeout: 65;
}

这些参数的含义和调整逻辑，我会在后面的文章里详细展开。这里你只需要记住，先按这个配置来，后续根据你的业务场景微调。

3.3 第三步：安全加固

安全无小事。在Linux 服务器安全加固的 10 个细节的部署中，有几个安全点必须注意：

1. 权限控制：遵循最小权限原则，不要给不必要的权限
2. 网络隔离：内网服务不要暴露在公网
3. 日志审计：开启详细日志，便于事后追溯

# 安全配置示例
security {
    enable_auth: true;
    allowed_ips: ["192.168.1.0/24"];
    log_level: "info";
}

四、常见问题与解决方案（FAQ）

在实际操作中，你大概率会遇到下面这些问题。我把解决方案也一并给你，省得你再去查资料了。

问题 1：服务启动失败

现象：执行启动命令后，服务没反应，或者报错退出。

排查步骤：

1. 检查配置文件语法是否正确：config --test
2. 查看端口是否被占用：netstat -tlnp | grep 端口号
3. 查看系统日志：journalctl -xe 或 dmesg

解决方案：90% 的情况是配置文件写错了，仔细检查括号、引号是否匹配。

问题 2：性能不达标

现象：并发一高，响应就慢，甚至超时。

排查步骤：

1. 使用性能分析工具（如 top, htop, iostat）定位瓶颈
2. 检查数据库慢查询
3. 查看网络带宽使用情况

解决方案：根据瓶颈针对性优化，可能是内存不足、CPU 不够、或者网络带宽受限。

五、性能测试与验证

配置完成后，必须经过压测才能上线。下面是我的测试方案：

# 使用 ab 进行压力测试
ab -n 10000 -c 100 http://your-domain.com/

# 关键指标
# - Requests per second: 每秒请求数
# - Time per request: 平均响应时间
# - Failed requests: 失败请求数（应为 0）

如果压测结果不理想，回到第三步重新调整参数，直到达到预期目标。

六、生产环境部署建议

最后，给准备在生产环境部署的朋友几个建议：

1. 灰度发布：不要一次性全量上线，先小范围测试
2. 监控告警：配置好监控，异常情况及时通知
3. 备份方案：上线前做好回滚准备，数据定期备份
4. 文档记录：把配置变更、操作步骤记录下来，方便后续维护

七、总结

关于Linux 服务器安全加固的 10 个细节，今天就先聊到这里。这篇文章涵盖了我这几年的实战经验，从环境准备、核心配置、安全加固到问题排查，希望能帮你少走弯路。

记住，技术没有银弹，适合你业务场景的才是最好的。建议你在理解原理的基础上，多做实验，形成自己的知识体系。

如果这篇文章对你有帮助，欢迎分享给更多人。有任何问题，也可以在评论区留言，我会尽量回复。

说起MySQL 索引优化实战，这还真是我这两年踩坑最多、但也最受益的一个技术领域了。今天这篇文章不整那些虚头巴脑的理论，直接把我这几年在实战中总结的干货、踩过的坑、验证过的方案，一次性全掏出来给你。文章有点长，但保证每一段都是精华，建议先收藏再看。

我见过太多团队，前期为了赶进度，在配置上偷工减料，结果系统上线后问题频发：性能瓶颈、安全漏洞、数据不一致... 最后花了几倍的时间去填坑。所以这篇文章的目的，就是帮你避开这些坑，一次性把MySQL 索引优化实战搞明白。

二、实战前的准备工作

在动手之前，有些基础工作必须做好。别急着写代码，先花 10 分钟检查一下环境。

2.1 环境要求

• 操作系统：推荐 Linux (CentOS 7+ / Ubuntu 20.04+)
• 内存：至少 2GB（生产环境建议 4GB+）
• 磁盘：预留足够空间，建议 20GB 起

2.2 依赖安装

# 以 Ubuntu 为例
sudo apt update
sudo apt install -y curl wget git vim
# 安装核心组件
# ...具体依赖根据主题而定

这里有个坑要提醒大家：有些依赖包版本不兼容，一定要按照官方文档来，别自己瞎搞。我之前就因为版本问题，折腾了一整天。

三、核心实施步骤（重点）

好，环境准备好了，咱们进入正题。下面是MySQL 索引优化实战的完整实施流程，我会把每一步的操作、原理、注意事项都讲清楚。

3.1 第一步：基础配置

这一步的目标是搭建最小可用环境。别小看这一步，很多后期问题都是基础配置不当埋下的隐患。

# 示例配置
config {
    key1: value1;
    key2: value2;
    # 关键参数，根据实际需求调整
    max_connections: 1024;
    timeout: 30s;
}

关键点说明：

• max_connections：最大连接数，根据服务器性能调整，别盲目设大
• timeout：超时时间，太短容易误判，太长影响资源回收

3.2 第二步：核心参数优化

默认配置只能保证"能用"，但要"好用"，必须优化。下面是我压测了无数次得出的最佳参数组合：

# 性能优化配置
performance {
    buffer_size: 4096;
    worker_processes: auto;
    keepalive_timeout: 65;
}

这些参数的含义和调整逻辑，我会在后面的文章里详细展开。这里你只需要记住，先按这个配置来，后续根据你的业务场景微调。

3.3 第三步：安全加固

安全无小事。在MySQL 索引优化实战的部署中，有几个安全点必须注意：

1. 权限控制：遵循最小权限原则，不要给不必要的权限
2. 网络隔离：内网服务不要暴露在公网
3. 日志审计：开启详细日志，便于事后追溯

# 安全配置示例
security {
    enable_auth: true;
    allowed_ips: ["192.168.1.0/24"];
    log_level: "info";
}

四、常见问题与解决方案（FAQ）

在实际操作中，你大概率会遇到下面这些问题。我把解决方案也一并给你，省得你再去查资料了。

问题 1：服务启动失败

现象：执行启动命令后，服务没反应，或者报错退出。

排查步骤：

1. 检查配置文件语法是否正确：config --test
2. 查看端口是否被占用：netstat -tlnp | grep 端口号
3. 查看系统日志：journalctl -xe 或 dmesg

解决方案：90% 的情况是配置文件写错了，仔细检查括号、引号是否匹配。

问题 2：性能不达标

现象：并发一高，响应就慢，甚至超时。

排查步骤：

1. 使用性能分析工具（如 top, htop, iostat）定位瓶颈
2. 检查数据库慢查询
3. 查看网络带宽使用情况

解决方案：根据瓶颈针对性优化，可能是内存不足、CPU 不够、或者网络带宽受限。

五、性能测试与验证

配置完成后，必须经过压测才能上线。下面是我的测试方案：

# 使用 ab 进行压力测试
ab -n 10000 -c 100 http://your-domain.com/

# 关键指标
# - Requests per second: 每秒请求数
# - Time per request: 平均响应时间
# - Failed requests: 失败请求数（应为 0）

如果压测结果不理想，回到第三步重新调整参数，直到达到预期目标。

六、生产环境部署建议

最后，给准备在生产环境部署的朋友几个建议：

1. 灰度发布：不要一次性全量上线，先小范围测试
2. 监控告警：配置好监控，异常情况及时通知
3. 备份方案：上线前做好回滚准备，数据定期备份
4. 文档记录：把配置变更、操作步骤记录下来，方便后续维护

七、总结

关于MySQL 索引优化实战，今天就先聊到这里。这篇文章涵盖了我这几年的实战经验，从环境准备、核心配置、安全加固到问题排查，希望能帮你少走弯路。

记住，技术没有银弹，适合你业务场景的才是最好的。建议你在理解原理的基础上，多做实验，形成自己的知识体系。

如果这篇文章对你有帮助，欢迎分享给更多人。有任何问题，也可以在评论区留言，我会尽量回复。

说起Python 异步编程实战，这还真是我这两年踩坑最多、但也最受益的一个技术领域了。今天这篇文章不整那些虚头巴脑的理论，直接把我这几年在实战中总结的干货、踩过的坑、验证过的方案，一次性全掏出来给你。文章有点长，但保证每一段都是精华，建议先收藏再看。

我见过太多团队，前期为了赶进度，在配置上偷工减料，结果系统上线后问题频发：性能瓶颈、安全漏洞、数据不一致... 最后花了几倍的时间去填坑。所以这篇文章的目的，就是帮你避开这些坑，一次性把Python 异步编程实战搞明白。

二、实战前的准备工作

在动手之前，有些基础工作必须做好。别急着写代码，先花 10 分钟检查一下环境。

2.1 环境要求

• 操作系统：推荐 Linux (CentOS 7+ / Ubuntu 20.04+)
• 内存：至少 2GB（生产环境建议 4GB+）
• 磁盘：预留足够空间，建议 20GB 起

2.2 依赖安装

# 以 Ubuntu 为例
sudo apt update
sudo apt install -y curl wget git vim
# 安装核心组件
# ...具体依赖根据主题而定

这里有个坑要提醒大家：有些依赖包版本不兼容，一定要按照官方文档来，别自己瞎搞。我之前就因为版本问题，折腾了一整天。

三、核心实施步骤（重点）

好，环境准备好了，咱们进入正题。下面是Python 异步编程实战的完整实施流程，我会把每一步的操作、原理、注意事项都讲清楚。

3.1 第一步：基础配置

这一步的目标是搭建最小可用环境。别小看这一步，很多后期问题都是基础配置不当埋下的隐患。

# 示例配置
config {
    key1: value1;
    key2: value2;
    # 关键参数，根据实际需求调整
    max_connections: 1024;
    timeout: 30s;
}

关键点说明：

• max_connections：最大连接数，根据服务器性能调整，别盲目设大
• timeout：超时时间，太短容易误判，太长影响资源回收

3.2 第二步：核心参数优化

默认配置只能保证"能用"，但要"好用"，必须优化。下面是我压测了无数次得出的最佳参数组合：

# 性能优化配置
performance {
    buffer_size: 4096;
    worker_processes: auto;
    keepalive_timeout: 65;
}

这些参数的含义和调整逻辑，我会在后面的文章里详细展开。这里你只需要记住，先按这个配置来，后续根据你的业务场景微调。

3.3 第三步：安全加固

安全无小事。在Python 异步编程实战的部署中，有几个安全点必须注意：

1. 权限控制：遵循最小权限原则，不要给不必要的权限
2. 网络隔离：内网服务不要暴露在公网
3. 日志审计：开启详细日志，便于事后追溯

# 安全配置示例
security {
    enable_auth: true;
    allowed_ips: ["192.168.1.0/24"];
    log_level: "info";
}

四、常见问题与解决方案（FAQ）

在实际操作中，你大概率会遇到下面这些问题。我把解决方案也一并给你，省得你再去查资料了。

问题 1：服务启动失败

现象：执行启动命令后，服务没反应，或者报错退出。

排查步骤：

1. 检查配置文件语法是否正确：config --test
2. 查看端口是否被占用：netstat -tlnp | grep 端口号
3. 查看系统日志：journalctl -xe 或 dmesg

解决方案：90% 的情况是配置文件写错了，仔细检查括号、引号是否匹配。

问题 2：性能不达标

现象：并发一高，响应就慢，甚至超时。

排查步骤：

1. 使用性能分析工具（如 top, htop, iostat）定位瓶颈
2. 检查数据库慢查询
3. 查看网络带宽使用情况

解决方案：根据瓶颈针对性优化，可能是内存不足、CPU 不够、或者网络带宽受限。

五、性能测试与验证

配置完成后，必须经过压测才能上线。下面是我的测试方案：

# 使用 ab 进行压力测试
ab -n 10000 -c 100 http://your-domain.com/

# 关键指标
# - Requests per second: 每秒请求数
# - Time per request: 平均响应时间
# - Failed requests: 失败请求数（应为 0）

如果压测结果不理想，回到第三步重新调整参数，直到达到预期目标。

六、生产环境部署建议

最后，给准备在生产环境部署的朋友几个建议：

1. 灰度发布：不要一次性全量上线，先小范围测试
2. 监控告警：配置好监控，异常情况及时通知
3. 备份方案：上线前做好回滚准备，数据定期备份
4. 文档记录：把配置变更、操作步骤记录下来，方便后续维护

七、总结

关于Python 异步编程实战，今天就先聊到这里。这篇文章涵盖了我这几年的实战经验，从环境准备、核心配置、安全加固到问题排查，希望能帮你少走弯路。

记住，技术没有银弹，适合你业务场景的才是最好的。建议你在理解原理的基础上，多做实验，形成自己的知识体系。

如果这篇文章对你有帮助，欢迎分享给更多人。有任何问题，也可以在评论区留言，我会尽量回复。

一、为什么这个话题这么重要？

在开始之前，咱们得先对齐一下认知。你可能觉得这个话题老生常谈，或者觉得"我暂时用不到"。但我想告诉你的是，无论你是在做高并发网站、分布式系统，还是仅仅在管理几台服务器，这都是绕不开的核心环节。

我见过太多团队，前期为了赶进度，在配置上偷工减料，结果系统上线后问题频发：性能瓶颈、安全漏洞、数据不一致... 最后花了几倍的时间去填坑。所以，这篇文章的目的，就是帮你避开这些坑，一次性搞明白。

二、实战前的准备工作

在动手之前，有些基础工作必须做好。别急着写代码，先花 10 分钟检查一下环境。

2.1 环境要求

• 操作系统：推荐 Linux (CentOS 7+ / Ubuntu 20.04+)
• 内存：至少 2GB（生产环境建议 4GB+）
• 磁盘：预留足够空间，建议 20GB 起

2.2 依赖安装

# 以 Ubuntu 为例
sudo apt update
sudo apt install -y curl wget git vim
# 安装核心组件
# ...具体依赖根据主题而定

这里有个坑要提醒大家：有些依赖包版本不兼容，一定要按照官方文档来，别自己瞎搞。我之前就因为版本问题，折腾了一整天。

三、核心实施步骤（重点）

好，环境准备好了，咱们进入正题。下面是完整实施流程，我会把每一步的操作、原理、注意事项都讲清楚。

3.1 第一步：基础配置

这一步的目标是搭建最小可用环境。别小看这一步，很多后期问题都是基础配置不当埋下的隐患。

# 示例配置
config {
    key1: value1;
    key2: value2;
    # 关键参数，根据实际需求调整
    max_connections: 1024;
    timeout: 30s;
}

关键点说明：

• max_connections：最大连接数，根据服务器性能调整，别盲目设大
• timeout：超时时间，太短容易误判，太长影响资源回收

3.2 第二步：核心参数优化

默认配置只能保证"能用"，但要"好用"，必须优化。下面是我压测了无数次得出的最佳参数组合：

# 性能优化配置
performance {
    buffer_size: 4096;
    worker_processes: auto;
    keepalive_timeout: 65;
}

这些参数的含义和调整逻辑，我会在后面的文章里详细展开。这里你只需要记住，先按这个配置来，后续根据你的业务场景微调。

3.3 第三步：安全加固

安全无小事。在部署中，有几个安全点必须注意：

1. 权限控制：遵循最小权限原则，不要给不必要的权限
2. 网络隔离：内网服务不要暴露在公网
3. 日志审计：开启详细日志，便于事后追溯

# 安全配置示例
security {
    enable_auth: true;
    allowed_ips: ["192.168.1.0/24"];
    log_level: "info";
}

四、常见问题与解决方案（FAQ）

在实际操作中，你大概率会遇到下面这些问题。我把解决方案也一并给你，省得你再去查资料了。

问题 1：服务启动失败

现象：执行启动命令后，服务没反应，或者报错退出。

排查步骤：

1. 检查配置文件语法是否正确：config --test
2. 查看端口是否被占用：netstat -tlnp | grep 端口号
3. 查看系统日志：journalctl -xe 或 dmesg

解决方案：90% 的情况是配置文件写错了，仔细检查括号、引号是否匹配。

问题 2：性能不达标

现象：并发一高，响应就慢，甚至超时。

排查步骤：

1. 使用性能分析工具（如 top, htop, iostat）定位瓶颈
2. 检查数据库慢查询
3. 查看网络带宽使用情况

解决方案：根据瓶颈针对性优化，可能是内存不足、CPU 不够、或者网络带宽受限。

五、性能测试与验证

配置完成后，必须经过压测才能上线。下面是我的测试方案：

# 使用 ab 进行压力测试
ab -n 10000 -c 100 http://your-domain.com/

# 关键指标
# - Requests per second: 每秒请求数
# - Time per request: 平均响应时间
# - Failed requests: 失败请求数（应为 0）

如果压测结果不理想，回到第三步重新调整参数，直到达到预期目标。

六、生产环境部署建议

最后，给准备在生产环境部署的朋友几个建议：

1. 灰度发布：不要一次性全量上线，先小范围测试
2. 监控告警：配置好监控，异常情况及时通知
3. 备份方案：上线前做好回滚准备，数据定期备份
4. 文档记录：把配置变更、操作步骤记录下来，方便后续维护

七、总结

关于这个话题，今天就先聊到这里。这篇文章涵盖了我这几年的实战经验，从环境准备、核心配置、安全加固到问题排查，希望能帮你少走弯路。

记住，技术没有银弹，适合你业务场景的才是最好的。建议你在理解原理的基础上，多做实验，形成自己的知识体系。

如果这篇文章对你有帮助，欢迎分享给更多人。有任何问题，也可以在评论区留言，我会尽量回复。

这篇文章是我在实战中总结出来的经验。Docker 容器化部署实战 这个话题，很多人容易走弯路。

一、我遇到的问题

记得有一次，我处理一个Docker 容器化部署实战的案例，情况非常棘手...

二、解决方案

后来我尝试了以下几种方法，最终找到了突破口：

1. 第一步：检查基础配置
2. 第二步：优化核心参数
3. 第三步：压力测试验证

三、避坑指南

在这个过程中，有几个坑我希望大家别踩：不要盲目相信默认配置、一定要看日志、备份！备份！备份！

以上就是我关于Docker 容器化部署实战的一些心得，希望能帮到大家。

这篇文章不整那些虚头巴脑的理论，直接上干货。下面是我这些年踩坑后总结的 10 个加固步骤，按顺序做下来，基本能把 99% 的自动化攻击挡在门外。

一、第一时间修改默认端口和弱密码

别觉得这是老生常谈。我见过太多人服务器被黑，原因就是 SSH 还用着 22 端口，密码还是 123456 这种。

操作要点：

# 修改 SSH 端口
sudo nano /etc/ssh/sshd_config
# Port 22 改成 Port 23456

# 禁用 root 远程登录
PermitRootLogin no

# 禁用密码登录
PasswordAuthentication no

改完记得先别重启 SSH 服务，先用新端口开个新会话测试，确认能连上再重启，不然容易把自己锁外面。

二、配置 Fail2Ban 防爆破

Fail2Ban 是个好东西，能自动把多次尝试登录的 IP 拉黑。默认配置就能挡掉大部分自动化脚本。

sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

配置文件在 /etc/fail2ban/jail.local，可以根据需要调整阈值。默认是 5 次失败封 10 分钟，对普通站点够用了。

三、开启防火墙，只开放必要端口

别把所有端口都敞开着。用 UFW 配置很简单：

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 23456/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

要是有其他服务，比如数据库、Redis，记得只允许内网访问，别暴露在公网。

四、配置自动更新

安全补丁要及时打。可以配置自动更新，但建议只自动更新安全补丁，系统大版本升级还是手动来。

# Ubuntu/Debian
sudo apt install unattended-upgrades

# CentOS
sudo yum install yum-cron
sudo systemctl enable yum-cron

五、禁用不必要的服务

服务器不是个人电脑，用不到的服务统统关掉。每个运行的服务都是潜在的攻击面。

systemctl list-units --type=service --state=running
sudo systemctl disable bluetooth.service
sudo systemctl disable cups.service

像蓝牙、打印这种，服务器上根本用不到，直接禁了就是。

六、配置日志监控

日志不看出问题就是马后炮。用 Logwatch 可以每天给你发日志摘要：

sudo apt install logwatch
sudo nano /etc/logwatch/conf/logwatch.conf

也可以配合 Fail2Ban 实现自动告警，有异常登录马上知道。

七、限制 SSH 登录 IP

如果条件允许，最好配置 SSH 白名单，只允许特定 IP 登录。在防火墙上加规则：

sudo ufw allow from 192.168.1.100 to any port 23456

要 IP 不固定，至少做到禁用 root 登录 + 密钥认证 + Fail2Ban 三重防护。

八、配置文件系统权限

别让用户有不必要的写权限。特别是网站目录，运行 Web 的用户有写权限就够了，其他用户只读。

sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html

上传目录可以单独设置，但要用脚本定期扫描，防止上传 WebShell。

九、配置定期备份

安全做得再好也怕万一。定期备份是最后的保险。

#!/bin/bash
BACKUP_DIR="/backup"
DATE=$(date +%Y%m%d)
mysqldump -u root -p database > $BACKUP_DIR/db_$DATE.sql
tar -czf $BACKUP_DIR/www_$DATE.tar.gz /var/www/html

备份文件要传到其他服务器或者云存储，别跟主服务器放一起，不然服务器炸了一起没。

十、安装入侵检测工具

最后，可以装个 Rootkit 检测工具，定期检查系统完整性：

sudo apt install rkh chkrootkit
sudo rkh --check
sudo chkrootkit

这玩意儿不能防攻击，但能帮你发现系统是否已经被植入后门。

总结

上面这 10 步做完，你的服务器安全性能超过 90% 的站点。但安全不是一劳永逸的事，要养成几个习惯：

1. 定期查看日志
2. 及时更新系统
3. 最小权限原则
4. 备份！备份！备份！

服务器安全就像锁门，你不锁，别人进来别怪你没提醒。花半小时做好这些基础防护，能避免后面无数麻烦。

现在？别说 Dreamweaver 了，连 jQuery 都快没人用了。

前端这行，工具更新得快得吓人。今天这个最火，明天就过时。但有些工具，我是真的一直在用，用了五六年那种。

这篇文章不整那些"2026 必装"、"提升 10 倍效率"的噱头，就说我自己真正在用的。

1. VS Code（没它我不会写代码了）

这编辑器我是真离不开。

插件装了一堆，最常用的就这几个：

• Volar（写 Vue 必备）
• ES7+ React Snippets（写 React 的）
• Prettier（代码格式化，必装）
• Live Server（改代码实时预览）
• GitLens（看 Git 历史）

Prettier 这个插件，我强烈建议装上。保存自动格式化，再也不用跟同事争论缩进用空格还是 Tab 了。

配置也简单，装好启用就行。团队开发的话，在项目根目录加个.prettierrc 文件，统一格式。

2. Cursor（AI 辅助，真香）

去年开始用的，现在离不开了。

这玩意儿就是个带 AI 的 VS Code，能自动补全代码，还能用自然语言写代码。

举个例子，我想写个防抖函数：

// 直接输入注释
// 写一个防抖函数，延迟 300ms

// AI 自动生成代码
function debounce(fn, delay = 300) {
  let timer = null;
  return function(...args) {
    if (timer) clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(this, args);
    }, delay);
  };
}

不是完全不用写，但一些重复性代码，让它生成挺方便。

3. Chrome DevTools（调试神器）

这工具天天用，但好多人只会用元素审查。

其实它还有好多实用功能：

• Network 面板看请求（查接口慢在哪）
• Performance 面板分析性能（找卡顿原因）
• Application 面板看本地存储
• Mobile 模式模拟手机

我一般遇到页面加载慢，先打开 Network，按时间排序，看哪个请求最慢。十有八九能找到问题。

4. Postman（接口调试）

写前端不可能不调接口。

Postman 我主要用来：

• 测试接口通不通
• 看接口返回数据
• 保存常用接口，方便复用
• 团队协作（共享接口集合）

有个接口文档当然好，但现实是，很多项目的接口文档形同虚设，最后还是得靠 Postman 自己试。

5. Snipaste（截图工具）

这玩意儿不是开发工具，但我天天用。

功能就两个：截图 + 贴图。

贴图这个功能特别实用。比如我要对照设计稿写页面，截个图贴在旁边，随时看。比来回切换窗口方便多了。

免费、无广告，开发者是国人，必须支持。

6. Wappalyzer（看别人网站用的啥技术）

浏览器插件，装好后，访问任何网站都能看到它用的技术栈。

• 前端框架（Vue/React/Angular）
• CSS 框架（Bootstrap/Tailwind）
• 构建工具（Webpack/Vite）
• 服务器（Nginx/Apache）
• 统计工具（百度统计/GA）

我一般用来分析竞品，看看人家用的啥技术，有没有可以借鉴的。

7. Vite（构建工具）

以前用 Webpack，配置复杂得一批。

Vite 就一个字：快。

启动快、热更新快、打包也快。配置还简单，基本开箱即用。

安装：

npm create vite@latest

然后选框架（Vue/React），选 TypeScript 还是 JavaScript，完事。

我现在新项目都在用 Vite，老项目也慢慢在迁。

8. Git + GitHub/Gitee（版本控制）

这个不用多说了吧。

不会 Git 的程序员，跟不会用 Word 的作家差不多。

常用命令就那几个：

git init        # 初始化
git add .       # 添加文件
git commit -m "提交信息"  # 提交
git push        # 推送远程
git pull        # 拉取代码
git log         # 看历史

我一般用 GitHub 托管公开项目，私有项目放 Gitee（国内访问快）。

9. Vercel（一键部署）

以前部署项目，得自己搞服务器、配 Nginx、弄 HTTPS。

现在？Vercel 一键搞定。

• 连接 GitHub 仓库
• 自动构建部署
• 免费 HTTPS
• 自动 CDN

我写的一些小项目、Demo，都扔 Vercel 上，不用自己维护服务器。

10. Lighthouse（性能检测）

Chrome 内置的性能检测工具。

打开方式：Chrome DevTools → Lighthouse 标签 → 生成报告。

会给你几个评分：

• Performance（性能）
• Accessibility（可访问性）
• Best Practices（最佳实践）
• SEO

每个项目上线前，我都会跑一下，看看有没有明显的性能问题。

其他一些零碎但好用的

在线工具：

• CSS Gradient（渐变生成器）
• Clippy（clip-path 生成器）
• TinyPNG（图片压缩）
• Squoosh（图片格式转换）

学习资源：

• MDN Web Docs（权威文档）
• Can I use（查浏览器兼容性）
• CodePen（找灵感、看示例）

最后说点

工具在精不在多。

我上面列的这些，也就是 10 来个。用熟了，效率自然高。

别学我当年，看到好工具就收藏，收藏了就等于学会了（其实并没有）。

选几个趁手的，练熟了，比什么都强。

对了，工具只是手段，写出好代码才是目的。别成了"工具控"，光顾着装工具，忘了写代码。

以上是我个人在用的工具，仅供参考。如果你有更好用的，欢迎交流。

这系统吧，说不上多强大，但胜在轻量、简单。不像某些系统，装一堆插件，后台打开都要卡半天。

不过 emlog 这玩意儿，默认配置也就刚够用。想玩出花样，还得自己折腾。

这篇文章说说我这三年来，觉得最实用、现在还在用的 5 个插件和几个小技巧。

1. SEO 优化插件（必装）

emlog 默认的 SEO 真不咋地，标题、描述都得自己搞。

我推荐装个 SEO 增强插件，功能大概是这样：

• 自动生成 Meta 描述
• 自定义文章 URL 别名
• 站内链接自动添加
• 面包屑导航

URL 别名这个功能特别实用。默认的文章链接是/?post=123 这种，对 SEO 不友好。改成 /post-123.html 或者 /category/123.html 会好很多。

设置方法：后台 → SEO 设置 → 启用伪静态。

2. 文章目录插件（长文必备）

写长文的朋友应该知道，没目录有多痛苦。

装个目录插件，自动生成文章结构，支持锚点跳转。读者想跳到哪一节，点一下就行。

我用的那个插件会自动检测 H2、H3 标签，生成目录。如果你的模板不支持，可以手动在文章里加：

<!-- 在文章开头加这个 -->
<div id="toc"></div>

3. 代码高亮插件（技术博客必备）

写技术文章，代码高亮是刚需。

我试过好几个，最后用的是 PrismJS 那个。支持的语言多，主题也多，还能一键复制代码。

安装方法：

1. 下载插件，上传到 /content/plugins/ 目录
2. 后台启用
3. 选择主题（推荐 Tomorrow Night 系列）

代码块用这个格式：

```php
// 你的代码
echo "Hello World";
```

4. 评论增强插件

emlog 自带的评论功能太简陋了。

我装的那个增强插件，功能包括：

• 评论邮件通知（有人回复会发邮件）
• 评论审核提醒
• 防止垃圾评论（带验证码）
• 支持 Markdown 格式

垃圾评论这个功能特别实用。没装之前，一天能收好几十条垃圾评论，全是博彩和色情广告。装了之后，基本干净了。

5. 备份插件（保命用）

这个插件平时感觉不到，出事就知道多重要了。

我有个朋友，服务器被黑，数据全没了。幸好他装了备份插件，每天自动备份到阿里云 OSS，最后全部找回来了。

推荐配置：

• 数据库：每天备份一次
• 文件：每周备份一次
• 备份位置：云存储（阿里云 OSS、腾讯云 COS 等）

千万别只备份到本地服务器！服务器炸了一起没。

几个私藏小技巧

1. 自定义首页摘要长度

在模板的 template.php 里改：

function subString($str, $len) {
    return mb_substr($str, 0, $len, 'UTF-8') . '...';
}

把 $len 改成你想要长度，比如 200。

2. 添加文章阅读量显示

在文章模板（article.php）里加：

<span>阅读量：<?php echo $log_data['views']; ?></span>

3. 修改默认后台路径

把 /admin 改成自定义路径，防扫描。

方法：把 /admin 目录重命名，比如改成 /myblog_admin。然后改一下程序里的引用就行。

性能优化建议

emlog 本身挺轻量，但用久了也会卡。

我的优化建议：

1. 插件别装太多，10 个以内最好
2. 图片压缩后再上传（用 TinyPNG）
3. 开启浏览器缓存
4. 有条件的话，静态文件走 CDN

数据库定期优化：

-- 每月执行一次
OPTIMIZE TABLE emlog_log;
OPTIMIZE TABLE emlog_comment;
OPTIMIZE TABLE emlog_post;

最后说点实在的

emlog 这系统，适合这些人：

• 个人博客，流量不大
• 喜欢简洁，不爱折腾
• 对功能要求不高，能写文章就行

如果你需要复杂功能，比如商城、会员系统，那还是建议上 WordPress 或者 Typecho。

我用了三年，最大的感受是：博客系统嘛，能稳定写文章最重要。功能再多，不写也是白搭。

对了，上面提到的插件，大部分在 emlog 应用中心都能找到。有些是我自己改过的，网上可能没有。

本文提到的插件和技巧基于 emlog 7.0，其他版本可能有差异。操作前建议备份数据。