你有没有遇到过这种情况：写了个爬虫抓100个页面，用 requests 一个个发，等了5分钟才跑完。然后你听说 Python 有个叫 asyncio 的东西能让速度翻10倍，打开文档一看——event loop、coroutine、awaitable……直接劝退。

别慌。asyncio 的核心思想就一句话：在等待 IO 的时候去干别的事。 就像你煮水的同时切菜，而不是傻站着等水开。

本教程用可运行、能复制粘贴立刻见效的代码带你从零掌握 asyncio，覆盖协程基础、Task并发、aiohttp异步爬虫、以及和 FastAPI（你如果看过本站的 FastAPI教程 就知道它底层完全靠 asyncio）的关系。

1. 同步 vs 异步：直观感受差距

先用一个简单的对比让数字说话。假设我们有3个任务，每个需要”等待”1秒（模拟网络请求）：

import time
import asyncio

# ===== 同步版本 =====
def sync_task(name, delay):
    print(f"{name} 开始")
    time.sleep(delay)  # 阻塞——CPU干等
    print(f"{name} 完成")

def sync_main():
    start = time.time()
    for i in range(3):
        sync_task(f"任务{i}", 1)
    print(f"同步耗时: {time.time() - start:.1f}s")

sync_main()
# 任务0 开始
# 任务0 完成
# 任务1 开始
# 任务1 完成
# 任务2 开始
# 任务2 完成
# 同步耗时: 3.0s

# ===== 异步版本 =====
async def async_task(name, delay):
    print(f"{name} 开始")
    await asyncio.sleep(delay)  # 非阻塞——让出控制权
    print(f"{name} 完成")

async def async_main():
    start = time.time()
    await asyncio.gather(
        async_task("任务0", 1),
        async_task("任务1", 1),
        async_task("任务2", 1),
    )
    print(f"异步耗时: {time.time() - start:.1f}s")

asyncio.run(async_main())
# 任务0 开始
# 任务1 开始
# 任务2 开始     ← 三个任务几乎同时开始
# 任务0 完成
# 任务1 完成
# 任务2 完成
# 异步耗时: 1.0s  ← 3秒变1秒

核心区别：time.sleep() 把整个线程卡住；asyncio.sleep() 在等待期间把控制权交还给 event loop，让它去执行其他协程。

2. async/await 语法速查

asyncio 的世界有三个核心概念：

# 最小可运行例子
import asyncio

async def hello():
    await asyncio.sleep(0.5)
    return "Hello, asyncio!"

result = asyncio.run(hello())
print(result)  # Hello, asyncio!

3. 并发执行：gather、create_task 和 TaskGroup

asyncio 提供了多种并发方式，各有适用场景：

3.1 asyncio.gather —— 最常用的并发

import asyncio

async def fetch(url):
    print(f"正在请求 {url}...")
    await asyncio.sleep(1)  # 模拟网络请求
    return f"{url} 的数据"

async def main():
    results = await asyncio.gather(
        fetch("https://api.example.com/users"),
        fetch("https://api.example.com/posts"),
        fetch("https://api.example.com/comments"),
    )
    print(results)

asyncio.run(main())
# 正在请求 https://api.example.com/users...
# 正在请求 https://api.example.com/posts...
# 正在请求 https://api.example.com/comments...
# ['https://api.example.com/users 的数据', ...]

特点：gather 按传入顺序返回结果。任何一个协程抛异常，gather 会把异常传播出来（除非设 return_exceptions=True）。

3.2 create_task —— 创建后台任务

async def main():
    # 创建 Task（立即被调度，不等 await）
    task1 = asyncio.create_task(fetch("url1"))
    task2 = asyncio.create_task(fetch("url2"))

    # 在这期间可以做别的事
    print("两个请求已发出，我干点别的...")
    await asyncio.sleep(0.5)

    # 最后收集结果
    r1 = await task1
    r2 = await task2
    print(r1, r2)

gather vs create_task 选择：

• 知道所有任务、要等全部完成 → gather
• 动态创建任务、想边发边干别的 → create_task

3.3 TaskGroup（Python 3.11+）—— 结构化并发

async def main():
    async with asyncio.TaskGroup() as tg:
        tg.create_task(fetch("url1"))
        tg.create_task(fetch("url2"))
    # 退出 with 块时自动等待所有任务完成
    print("全部完成！")

相比 gather，TaskGroup 的好处是：任何一个子任务出错，其他子任务自动取消，不会留下僵尸任务。

4. 实战：用 aiohttp 做异步爬虫

asyncio 最经典的应用场景就是异步爬虫。我们把之前 Python 爬虫入门教程 里的 requests 同步方案升级为异步：

import asyncio
import aiohttp
import time

# 安装: pip install aiohttp

async def get_title(session, url):
    try:
        async with session.get(url, timeout=10) as resp:
            html = await resp.text()
            # 简单提取 <title> 标签
            start = html.find("<title>") + 7
            end = html.find("</title>", start)
            title = html[start:end] if start > 6 else "无标题"
            return url, resp.status, title[:60]
    except Exception as e:
        return url, 0, str(e)[:50]

async def main():
    urls = [
        "https://www.python.org",
        "https://docs.python.org/3/library/asyncio.html",
        "https://pypi.org/project/aiohttp/",
        "https://github.com",
        "https://fastapi.tiangolo.com",
        "https://www.devlearn.club",
    ]

    start = time.time()
    async with aiohttp.ClientSession() as session:
        tasks = [get_title(session, url) for url in urls]
        results = await asyncio.gather(*tasks)

    elapsed = time.time() - start
    print(f"抓取 {len(urls)} 个页面，耗时 {elapsed:.2f}s\n")
    for url, status, title in results:
        print(f"[{status}] {url}")
        print(f"  → {title}")

asyncio.run(main())
# 抓取 6 个页面，耗时 1.23s

同样的任务用 requests 同步版要 6+ 秒。这就是 asyncio 的威力——IO 密集场景下，速度几乎等于最慢那个请求的时间。

4.1 进阶：限制并发数（Semaphore）

直接对100个URL发起100个并发请求可能被服务器封IP，也可能打满带宽。用 asyncio.Semaphore 控制并发：

async def fetch_with_limit(session, url, semaphore):
    async with semaphore:  # 最多 N 个协程同时进入
        return await get_title(session, url)

async def main():
    sem = asyncio.Semaphore(10)  # 最多同时10个请求
    async with aiohttp.ClientSession() as session:
        tasks = [fetch_with_limit(session, url, sem) for url in urls]
        results = await asyncio.gather(*tasks)

5. 常见陷阱与最佳实践

5.1 不要在协程里调用同步阻塞函数

# ❌ 错误：time.sleep 阻塞了整个 event loop
async def bad_example():
    time.sleep(5)  # 整个事件循环卡住5秒

# ✅ 正确：使用 asyncio 版本的 sleep
async def good_example():
    await asyncio.sleep(5)

# ✅ 或者把阻塞调用丢到线程池
async def better_example():
    await asyncio.to_thread(time.sleep, 5)  # Python 3.9+

5.2 别忘了 await

async def main():
    # ❌ 不会被执行——协程只是创建了，没有调度
    fetch("url")

    # ✅ 必须 await 或 create_task
    await fetch("url")
    # 或
    asyncio.create_task(fetch("url"))

5.3 异常处理

results = await asyncio.gather(
    fetch("url1"),
    fetch("url2"),
    return_exceptions=True  # 异常不会中断其他任务
)
for r in results:
    if isinstance(r, Exception):
        print(f"出错: {r}")
    else:
        print(f"成功: {r}")

5.4 Event Loop 冲突

在 Jupyter Notebook、某些 Web 框架或已经运行 event loop 的环境里，asyncio.run() 会报 RuntimeError: Event loop is already running。解决方案：

# Jupyter 里直接用 await（不需要 asyncio.run()）
await fetch("url")

# 或者在已有 loop 的环境里
loop = asyncio.get_event_loop()
loop.create_task(fetch("url"))

6. asyncio 在 Web 框架中的应用

你之前在本站看到的 FastAPI 教程 和 Flask 教程，它们对异步的处理完全不同：

如果你要用 SQLAlchemy 做异步数据库操作，可以参考本站 SQLAlchemy Async 教程。

7. 速查表：常用 asyncio API

常见问题（FAQ）

总结

asyncio 不是银弹，但它是 Python 解决 IO 并发问题最优雅的方案。三个关键点记住：

1. 遇到 await 就暂停，先去干别的
2. gather 批量并发，Semaphore 控制上限
3. 别在协程里调同步阻塞函数

下一步建议：把之前用 requests 写的爬虫改成 aiohttp 版，亲身体验速度差；然后看看 FastAPI 的源码，你会发现路由处理函数全是 async def——这就是 asyncio 在生产环境中最常见的形态。

Python asyncio教程：从协程基础到异步爬虫实战完整指南最先出现在编程·投资·科技。

如果你持有A股红利股超过一年，你肯定经历过这个魔幻场景：

6月到7月，手机叮叮叮响个不停——工商银行分了、长江电力分了、中国神华分了、大秦铁路分了……账户里一下子多了好几万。爽得不行。然后呢？8月、9月、10月……账户安静得像死了一样。一直到明年6月，整整10个月没有任何分红进账。

这就是A股红利投资者的经典困境：分红高度集中在5-7月，全年11个月空窗期。对于靠股息生活的FIRE族来说，这个现金流节奏简直反人类——你不可能一年只花一次钱，对吧？

我有个朋友（真事），2024年拿了大概12万分红，其中8万集中在6-7月。他那两个月花钱如流水，结果到年底又要从本金里掏钱过日子。这就是典型的「分红现金流错配」——不是钱不够，是钱来的时间不对。

今天这篇文章，就是要解决这个问题：怎么让你的红利组合，像发工资一样每个月都有钱到账？

太长不看版：A股红利股天然集中在6-7月分红，但通过精选中期分红股（中石化、格力等）+ 搭配港股/REITs/可转债利息收益，可以显著平滑现金流。关键是不要在构建组合时只看股息率，还要看派息节奏。

A股分红日历：10只核心红利股派息月份一览

先看一张图。这是A股10只最主流红利股的派息月份分布：

看到了吗？9只股票的蓝色方块全部挤在6、7月。只有中国石化和格力电器分散了一点点到8月、9月。1-5月、10-12月——空白。

这10只股票的具体数据：

这10只股票如果等权买入，你的年分红收入中 85%会在6-7月到达。剩下10%在8月，5%在9月。其他9个月——零。

这就是为什么即使你的股息收入在纸面上够了，实际生活中还是觉得捉襟见肘。不是你赚得少，是钱来得太集中。

为什么A股分红这么「扎堆」？

这里有个制度性原因：A股上市公司绝大多数以自然年（1-12月）为会计年度。年报在次年4月30日前披露，股东大会在6月左右召开，分红方案通过后一到两个月实施。所以几乎所有公司的分红都落在6-7月。

对比一下美股：很多美国公司按季度分红，每年4次，每次季报后派息。持有10只美股红利股，你基本上每个月都能收到几笔股息。A股天然就不具备这个优势——年分红一次是常态，半年分红是惊喜，季度分红是异类。

不过好在中国石化是个特例——每年两次分红（中期+末期），分别在6月和9月。它就像是那个「打破规矩」的人，给了我们一点操作空间。

实操方案：四招平滑全年现金流

第一招：重仓「双分红」股

把所有钱都砸进一年分两次红的公司。A股里最典型的就是中国石化（600028）：6月末期分红，9月中期分红。两次加起来股息率约5%。

但这个策略有个硬伤：鸡蛋都在一个篮子里。石化股受油价影响大，万一油价暴跌，分红可能缩水。FIRE追求的是确定性，单押一只周期股风险太大。

实操建议：组合中给中国石化10-15%的仓位，作为「9月现金流锚点」，但不要ALL IN。

第二招：提前预留缓冲池

这是最简单也最容易被忽视的方法：6-7月分红到账后，不要全花掉。把其中40-50%转入一个货币基金或短期理财账户，平均分配到接下来10个月使用。

举个例子：假设你6-7月收到8万分红。把其中4万放进余额宝/零钱通，每个月自动转出4000元作为生活费。这样虽然分红本身没变，但通过人为平滑，你的现金流就均匀了。

这个方法几乎零成本，只要有纪律就行。缺点也很明显：需要自制力，而且那笔钱在你手里躺着的时候会被通胀吃掉一点。

全年总分到9万，月均7500元。通过缓冲池平滑后，你每个月都有4000元稳定现金流，剩余部分作为来年本金再投资。

第三招：跨市场分散（A股+港股+REITs）

A股分红集中在年中，但港股不一样。很多港股公司按半年分红或季度分红，时间点错开。举个例子：

港股的力量：汇丰控股通常在Q1和Q3派息，中国移动H股在年中+年末派息。如果你持有30%仓位在港股，全年现金流的平滑度会大幅提升。

但这里有个门槛：港股通需要50万资产门槛。如果你的FIRE本金还没到这个水平，先用缓冲池法（第二招）过渡。

第四招：可转债利息补充（零风险补充收入）

这招很多人没注意到：可转债每年派息1-2次，而且和股票分红时间经常错开。更重要的是，可转债有保底——到期还本付息。

举个例子：某AAA级可转债，面值100元，票面利率第一年0.3%、第二年0.5%……第六年2%。利率不高，但它每年固定付息。如果你有50万闲置资金配置在可转债上，每年能拿到2000-4000元的确定性利息，正好填补1-5月的空窗期。

而且可转债还有隐含期权价值（转股权），如果正股大涨你能跟着喝汤。即便不涨，到期拿回本金+利息，不会亏。

复利计算：平滑现金流对长期收益的影响

很多人觉得「平滑现金流」只是个生活质量问题，和收益无关。其实关系大了。

假设你有200万本金，全部投在股息率5%的红利组合上。每年6月拿到10万分红。现在对比两种花法：

方案A（不管理）：6月一次性拿到10万，立刻花掉4万（一年生活费），剩下6万再投资。下一年同样的循环。

方案B（缓冲池管理）：6月收到10万，分12个月均匀花掉，每月花3333元。同时把未花的钱放进货基赚2%年化。年底结余0元用于再投资（因为都花掉了）。

方案C（最优化）：6月收到10万，70%放进缓冲池（平滑到下一年），30%立即再投资。每月只花掉分红中的40%，剩余全部滚入本金。

对比20年后的结果（假设股息率维持5%，分红再投资复利）：

同样200万起步，优化现金流管理比随便花多出90万本金和每年多4.5万分红。差别就来自于「未花的钱有没有在赚钱」——哪怕只是货基的2%，积少成多20年也吓人。

这里用小学数学算一下复利效应：200万×(1.05)^20 ≈ 200万×2.653 ≈ 530万（如果完全不花钱全部再投资）。但FIRE你不能不吃不喝。方案C相当于每年花掉2%（4万/200万），再投资3%（6万/200万），有效复利增速约3%。200万×(1.03)^20 ≈ 200万×1.806 ≈ 361万。实际会更高一些，因为缓冲池的钱也有货基收益。

实操组合示例：100万本金搭建「月月有工资」组合

以下是我个人会用的配置方案（不是投资建议，纯交流）：

这个组合的关键不是收益多高，而是可转债和货基提供了6-7月之外的现金流。当A股红利股全部熄火的下半年，你有：

• 9月：中国石化中期分红约3700元
• 全年：可转债利息约3000元（按季度或半年付息）
• 全年：货基/短债利息约3000元（随时可取）

再配合第二招的缓冲池管理，从6-7月到账的28330元中划出14000元分10个月花，你每个月实际可支配约3100-3500元。在大部分二三线城市，一个人简朴但体面的生活完全够用。

FAQ

总结：三个层次解决现金流问题

回顾一下，FIRE红利投资面临的核心矛盾是：A股年分红制 vs 月月都要花钱。解决方案分三个层次：

第一层（必做）：分红到手后人为平滑——把大头放进货基/短债，按月支取。这是所有FIRE投资者都应该做的事，不论本金大小。

第二层（进阶）：在组合中刻意配置非6-7月分红的资产——中国石化（9月）、可转债（全年）、A股REITs（分散时点）。这需要你对每种资产的派息节奏做点功课。

第三层（高阶）：跨市场配置——港股、美股红利股或ETF，实现真正的全年12个月不间断现金流。这需要50万+的本金和一定的投资经验。

记住FIRE的核心不是「有多少钱」，而是「钱来的节奏能不能匹配你花钱的节奏」。一个每年6月拿20万但全年其他月份零收入的人，过得比每个月稳定拿1.2万的人焦虑得多。现金流平滑度本身就是一种安全感。

最后说一句大实话：不管你用什么方法平滑现金流，高股息+复利+长期持有=FIRE 这个大逻辑不变。本文讨论的所有技巧都是锦上添花，不是雪中送炭。真正的核心始终是：选好公司，持续买入，别乱动，让时间给你赚钱。

相关阅读：Yield on Cost才是FIRE的终极答案——每月定投5000元30年后股息率变成48.7% | 分红再投资 vs 花掉，20年后差距让你怀疑人生 | 月领3000/5000/8000/10000元退休金需要多少银行股？

免责声明：本文所有内容仅为个人投资思考与经验分享，不构成任何形式的投资建议。文中提及的所有股票、ETF、可转债均为举例说明，不代表推荐买入或卖出。股票市场存在风险，过往分红记录不代表未来表现。任何投资决策请基于你自己的独立研究和风险承受能力做出。作者持有文中提及的部分股票。

高股息FIRE之路：A股分红高度集中在6-7月，如何让每个月都有“工资”到账？最先出现在编程·投资·科技。

如果你问一个 Linux 老手「你最常用的命令是什么」，find 大概率排在前三。它不是 ls 那种「看一眼」的工具，而是真正的「搜索引擎」——按名称、大小、时间、权限、所有者、文件类型……几乎所有维度，它都能精准定位。

但现实中，很多人对 find 的使用停留在 find . -name "*.log" 这个层次。本文从 12 个真实生产场景出发，带你从入门到精通。

测试环境：Ubuntu 24.04 LTS，find 版本 4.9.0（GNU findutils）。所有示例可直接复制运行。

一、基础篇：find 的核心语法

$ find [路径] [表达式] [动作]

如果省略路径，默认从当前目录 . 开始。如果省略动作，默认执行 -print，即打印匹配的文件路径。

$ find /var/log -name "*.log"
/var/log/syslog
/var/log/auth.log
/var/log/kern.log

二、12 个生产环境实战场景

场景 1：按文件名查找

最常见的用法——在 /etc/nginx 下找所有 .conf 文件：

$ find /etc/nginx -name "*.conf"
/etc/nginx/nginx.conf
/etc/nginx/sites-available/default
/etc/nginx/conf.d/ssl.conf

如果需要忽略大小写，用 -iname：

$ find /var/log -iname "*.LOG"

场景 2：按文件类型查找

-type 是最实用的过滤条件之一：

$ find /etc -type d -name "nginx"
/etc/nginx

找当前目录下所有空目录：

$ find . -type d -empty

场景 3：按文件大小查找

运维排障的救命稻草——磁盘满了，谁在吃空间？

$ find /var/log -type f -size +100M
/var/log/journal/d7b3.../system.journal

大小单位对照：

注意：+100M 是大于 100MB，-100M 是小于 100MB，100M 是精确 100MB（极少用到）。

场景 4：按修改时间查找

「昨天谁改了这个配置文件？」——-mtime 告诉你答案。

$ find /etc/nginx -name "*.conf" -mtime -1
/etc/nginx/sites-available/default

时间参数速查：

清理 30 天前的临时文件：

$ find /tmp -type f -mtime +30 -delete

警告：-delete 不可逆！建议先用 -print 预览，确认无误再执行。

场景 5：按权限查找

安全审计必备——找出权限过于宽松的文件：

$ find /var/www -type f -perm 777
$ find /etc -type f -perm /o+w 2>/dev/null

-perm /o+w 匹配任何「其他人可写」的文件，2>/dev/null 屏蔽权限不足的错误提示。

场景 6：按所有者查找

$ find /var/www -user www-data
$ find /home -group developers

找出不属于任何用户的孤儿文件：

$ find /srv -nouser

场景 7：多条件组合（AND / OR）

find 默认是 AND 逻辑，用 -o 实现 OR，用 ( ) 分组：

$ find /var/log \( -name "*.log" -o -name "*.gz" \) -mtime -1

等价于：找最近 1 天内修改的 .log 或 .gz 文件。

场景 8：对匹配文件执行操作（-exec）

这可能是 find 最强大的能力——找到文件后，立即对它做点什么。

批量修改权限：

$ find /var/www -type f -name "*.sh" -exec chmod +x {} \;

批量压缩旧日志：

$ find /var/log -type f -name "*.log" -mtime +30 -exec gzip {} \;

{} 是匹配文件名的占位符，\; 表示命令结束。如果想把多个文件一次性传给命令，用 + 替代 \;：

$ find /var/log -name "*.log" -exec du -sh {} +

场景 9：配合 xargs 处理海量文件

当匹配文件数量极大（数万、数十万），-exec 每次启动一个进程，效率低。xargs 批量处理：

$ find /data -type f -name "*.tmp" -print0 | xargs -0 rm -f

-print0 和 -0 配合，安全处理文件名中包含空格、换行等特殊字符的情况。

场景 10：按深度限制搜索范围

$ find / -maxdepth 3 -name "nginx.conf" 2>/dev/null
/etc/nginx/nginx.conf
/usr/share/doc/nginx-common/examples/nginx.conf

-maxdepth 限制向下搜索层数，-mindepth 限制起始层数：

$ find /var/log -mindepth 2 -type f

跳过 /var/log 本身，只搜子目录里的文件。

场景 11：排除指定目录

$ find / -path /proc -prune -o -path /sys -prune -o -name "*.conf" -print 2>/dev/null

-prune 排除指定路径，避免扫描 /proc、/sys 等虚拟文件系统。

场景 12：按 inode 查找与去重

找硬链接——两个文件名指向同一个 inode：

$ find /home -type f -links +1

按 inode 号查找（当你需要删除文件名包含奇怪字符的文件时）：

$ ls -i  # 先找到 inode 号
$ find . -inum 458752 -delete

三、find 与其他命令的黄金组合

find + grep：搜文件内容

$ find /etc/nginx -name "*.conf" -exec grep -l "proxy_pass" {} \;

在所有 nginx 配置文件中搜包含 proxy_pass 的。

find + stat：批量查看文件详情

$ find /var/log -name "*.log" -mtime -1 -exec stat --format="%n %s %y" {} \;

find + tar：打包指定时间范围的文件

$ find /var/log -name "*.log" -mtime -7 | tar -czf weekly_logs.tar.gz -T -

四、性能优化建议

1. 指定具体路径：find /var/log 比 find / 快几百倍。
2. 类型过滤放前面：-type f -name "*.log" 先筛掉目录，减少后续匹配量。
3. 减少 -exec 调用次数：用 + 替代 \;，或用 xargs。
4. 合理使用 prune：排除不关心的目录，如 /proc、/sys、.git。
5. 善用 maxdepth：不需要深层递归时设置 -maxdepth 3。

五、速查表

延伸阅读：

• Linux 常用命令大全：文件操作、文本处理、网络与系统管理速查手册
• Linux crontab 定时任务完全指南（2026）
• Linux 磁盘管理完全指南：分区、挂载与 LVM 扩容实战（2026）

Linux find命令用法详解：文件查找的12个实战场景（2026）最先出现在编程·投资·科技。

这是我被问过最多的问题，没有之一。

每次我说「靠股息生活」，就有人跳出来：「股价除息那天就跌掉分红金额了，你分到的钱其实就是你自己的本金，哪有赚？」

说实话，我第一次买银行股分红时也懵过。2021年买了某行，4块钱一股，分了0.22元，结果第二天开盘直接变3.78元。账面总资产一分没多——分红的2200块现金+市值37800，刚好等于分红前的40000块。

当时我的反应跟你一样：这不就是左手倒右手吗？

但三年后回头看，我发现了一个被绝大多数人忽略的现象——这只股票后来涨回了4块，还超过了。而我那2200块分红已经在低位买成了更多股票，下一年的分红基数变大了。

今天这篇文章，我用A股十年数据把这件事彻底讲清楚。如果你也在纠结「分红到底赚不赚」，看完就明白了。

先搞懂：除息和填权是怎么回事

这是两个被中文翻译搞复杂了的概念。用大白话说：

• 除息：公司每股分1块钱，第二天开盘价自动减1块。这是交易所规则，不是股价真跌了。
• 填权：除息后股价慢慢涨回来，把那个”缺口”补上。这才是你真正赚钱的地方。

举个例子：中国神华2025年每股分红2.26元。除息前一天收盘40元，除息日开盘直接调到37.74元。如果你在这天之前买的，账面确实没多一分钱——分红2.26元现金+股价跌2.26元=0。

但接下来的事情才是关键：中国神华用了大概2个月，股价从37.74元涨回到了40元附近。填权完成后，你账户里多出来的那笔分红现金，就成了真正的纯收益。

用一张表看得更清楚：

看到没？除息日总资产不变，但填权后多出来的2.26万就是白赚的。

A股高息股填权成功率有多高？

废话不多说，我们直接拉数据。我统计了A股中证红利指数成分股最近5年的除息-填权表现：

核心发现：优质高息股的填权成功率接近100%。填权时间一般在1-3个月。只要公司基本面没有恶化，市场总会把那个除息缺口补回来。

为什么？因为这些公司每年都在稳定赚钱、稳定分红。每股1块钱的红利分出去，公司账上少1块，但明年还能再赚回来1块多。市场不是傻子，不会让一只每年赚6%分红率的股票永远跌掉6%。

FIRE实战：填权+再投资=双重复利

现在进入本文最硬核的部分。

假设你从2016年6月开始，投入50万元买入3只高息股（工行+神华+长江电力，等权重），每年收到分红后全部以当时价格再买入。我们模拟一下到2026年6月的效果：

10年结果：50万变108万，年化收益率约8%。每年拿到的现金分红从2.8万涨到了5.5万——年分红金额翻了近一倍。

这还没算银行股本身的股价涨幅（工行2016年约4元，2026年约7元）。如果算上，总收益率会更高。

但我故意只算了分红再投资的效果。因为我想说明一件事：就算股价完全不动，只要公司持续盈利、持续分红、填权成功，你的分红现金流也会自己长大。

一个月投4000元，20年后每月领多少？

这是FIREer最关心的问题。我们来算一笔账：

假设你从现在开始，每月投入4000元到高息股组合（平均股息率5.5%），每年分红全部再投资，股价长期温和上涨（填权+年均2%增长）。

20年后的结果：

20年后，你每月能从股息中领到8300多元。而且这笔钱还在增长——因为股价在涨、分红也在涨。本金96万变成近190万，其中差不多94万是分红再投资+填权带来的复利效应。

如果你能每月投入8000元，20年后月领股息直接跳到1.6万元。在大多数二三线城市，这已经超过了普通上班族的工资。

填权不成功怎么办？——三个避坑原则

不是所有高息股都能填权。有些股票分完红就一蹶不振，那个”缺口”永远补不上。这时候你的分红确实变成了”割自己的肉”。

怎么避免这种情况？三个原则：

1. 只买「赚钱机器」，不买「分红机器」

有些公司为了维持高股息率，借钱分红、卖资产分红。这种填不了权。要看ROE（净资产收益率）——ROE持续>10%的公司才有填权的内生动力。工商银行ROE长期10%+，中国神华ROE 13%+，长江电力ROE 14%+。

2. 避开周期顶部的超高股息

煤炭股在煤价高位时股息率能到10%+，看起来很香。但煤价一跌，盈利腰斩，股息率瞬间崩塌，股价也不会填权。买在周期顶部的高息股是最大的坑。

3. 分散持有，不押一只

就算你研究的再透，也可能踩雷。5-8只不同行业的高息股分散持有，就算一只填权失败，其他几只填了，整体还是赚的。

FIREer的终极策略：不卖股，只吃息

理解了填权，你就理解了为什么FIREer不需要卖股票。策略是这样的：

1. 建仓期（5-10年）：每月定投，分红全再投，让股数和分红基数螺旋增长
2. 过渡期（3-5年）：减持部分本金用于生活，大部分仍持有收息
3. 自由期：完全靠股息生活，股价涨跌与你无关——你只需要每年6-8月那笔分红到账

当你的年股息收入 > 年生活支出时，你就FIRE了。股价涨到天上也好、跌到地板也好，只要公司还在赚钱分红，你的生活不受任何影响。

这就是「靠资产生活」的本质——你不是在赌股价涨跌，你是在分享优质公司的经营利润。

常见问题（FAQ）

总结：填权是FIREer最好的朋友

很多人看股息率只算一个数：5%就是5%。但实际收益远不止5%，因为：

1. 填权效应：除息缺口被补回来，分红变成纯利润
2. 分红再投资：分红买更多股 → 下一年分更多 → 再买更多
3. 股息增长：好公司每年利润增长，分红也跟着涨（工行近10年股息年增约5%）
4. 长期持有免税：持股超1年分红不收税

这四件事叠加，就是FIRE的数学基础。不是赌、不是投机、不需要每天盯盘——只需要耐心和纪律。

核心公式：高股息 + 填权 + 分红再投资 + 长期持有 = FIRE

看完这篇文章，下次有人跟你说「分红就是左手倒右手」，你可以把这篇文章甩给他。

免责声明

本文仅为个人学习笔记和投资思考分享，不构成任何投资建议。文中提及的所有股票仅供分析说明之用，不代表买入或卖出推荐。股票投资有风险，过往业绩不代表未来表现。每个人的财务状况、风险承受能力和投资目标不同，请独立判断或在专业人士指导下做出投资决策。作者对因本文内容导致的任何投资损失不承担责任。

相关阅读：

• 每月投5000元到A股红利股，30年后你的「股息率」会变成48.7%
• 同样100万买红利股，分红再投资vs花掉，20年后差距让你怀疑人生
• 高股息FIRE策略：每月定投5000元，20年后财务自由
• 高股息FIRE本金速算：月领3000/5000/8000/10000元退休金，需要多少A股银行股？
• 高股息FIRE三剑客：中国神华 vs 长江电力 vs 大秦铁路

高股息FIRE之路：分红除息后股价跌了，我的钱白分了吗？——「填权」真相大揭秘最先出现在编程·投资·科技。

GitHub Copilot 已经装机超过200万开发者了。但我打赌——90%的人只用到了它20%的功能。

你也是「Tab补全第一行就完事了」那种用法对吧？我也是，直到我发现这些隐藏功能之后，才意识到自己一直在「用钥匙当锤子使」。

这篇文章整理了10个我日常用得最多的 Copilot 高级功能——不是那种官网文档第一页就写着的，而是真正用了一段时间才会发现的「隐藏技」。学完这些，你的编码效率可能再翻一倍。

测试环境：VS Code 1.98 + GitHub Copilot v1.280 + Copilot Chat v0.24（2026年5月）

十大隐藏功能速览

#	功能名称	激活方式	效率评级
1	@workspace 代理	聊天窗口输入 @workspace
2	精确上下文变量	#file / #selection / #terminalLastCommand
3	自定义指令文件	.github/copilot-instructions.md
4	/explain 命令	选中代码后输入 /explain
5	/fix 命令	选中 bug 代码后输入 /fix
6	/tests 命令	选中函数后输入 /tests
7	多建议面板	Ctrl+Enter 打开备选列表
8	内联聊天 Cmd+I	选中代码后按 Cmd+I / Ctrl+I
9	文件排除设置	Settings 搜索 “copilot exclude”
10	自动生成 Commit Message	Source Control 面板点按钮

功能一：@workspace 代理——让 Copilot 理解你的整个项目

这是 2024 年底推出的功能，但我至今遇到的开发者里用过的不超过3个。

普通 Copilot Chat 只看你当前打开的文件。而 @workspace 代理会扫描整个项目的文件结构、依赖关系、配置，然后基于全局上下文回答你。

典型用法：

@workspace 这个项目的认证逻辑是怎么实现的？帮我画出数据流
@workspace 有哪些地方用了硬编码的 API 地址？帮我列出来
@workspace 我要在这个项目里加一个导出 CSV 的功能，应该改哪些文件？

说实话，第三个问题是 @workspace 最让我上头的场景。以前加新功能要先花 20 分钟翻代码找到正确的切入点，现在直接问——它告诉你要改 xxService、xxController、xxDTO，连文件路径都给你列好了。

亮点：跨文件理解能力碾压普通 Chat，重构/接手遗留代码时的救星。

不足：超大项目（500+文件）首次扫描要 10-15 秒，且需要 GitHub Copilot Business/Enterprise 订阅。

功能二：精确上下文变量——别再复制粘贴代码了

这个功能简单到容易被忽略，但它可能是日常使用频率最高的隐藏技巧。

在 Copilot Chat 里，你可以用 # 引用具体的上下文：

#terminalLastCommand 是我最常用的——测试跑挂了，不用手动复制粘贴报错信息，直接一个变量扔给 Copilot 让它分析。

小技巧：#file 支持模糊匹配文件名，不需要打完整路径。

功能三：自定义指令文件——定义你的AI编码规范

这个功能藏在文档深处，但价值巨大。

在项目根目录创建 .github/copilot-instructions.md，Copilot 会在每次生成代码时自动读取这个文件作为行为准则。

示例文件内容：

# Copilot 编码指令

## 代码风格
- 使用 TypeScript strict mode
- 函数优先使用箭头函数
- 变量命名用 camelCase，组件用 PascalCase
- 禁用 any 类型，必须显式声明

## 错误处理
- 所有 API 调用必须有 try/catch
- 错误信息必须包含上下文，不能用通用 message

## 注释规则
- 公开 API 必须有 JSDoc
- 复杂业务逻辑加行内注释
- 不要写解释"是什么"的注释，只写"为什么"

## 测试
- 每个 service 方法必须有对应单元测试
- 使用 vitest，不用 jest

配好之后效果立竿见影——Copilot 生成的代码不再是你团队的「异类」，风格直接对齐你的规范。

一个真实经历：我们团队统一了 copilot-instructions.md 之后，Code Review 里「格式不统一」的评论减少了大约 60%。

功能四：/explain——让AI当你的代码老师

接手别人的代码最痛苦的是什么？读不懂。尤其是那种一个函数 200 行、变量名叫 tmp1、tmp2、data 的祖传代码。

选中那段代码，在 Copilot Chat 输入 /explain：

/explain 这段代码在做什么？用通俗的语言解释

Copilot 会输出：这段代码处理的是订单状态机——从「待支付」到「已取消」的过期逻辑，包括库存回滚、优惠券退还、通知发送三步。

比自己一行行啃快 10 倍，而且它还会标注出哪些地方可能有 bug。

进阶用法：加一个「用5岁小孩能理解的方式解释」，它会给出超接地气的比喻。

功能五：/fix——一键修复Bug

选中出问题的代码，输入 /fix，Copilot 会自动分析问题并给出修复后的代码。

不只是修语法错误——它能识别逻辑问题。比如你写了一个 for 循环但忘记处理边界条件，/fix 不仅会补上，还会在注释里说明为什么原来的代码有问题。

/fix 这段代码在处理空数组时会崩溃，帮我修一下

比 StackOverflow 快，比 Google 精准。而且它给的修复代码可以直接「Apply」到编辑器里，不用复制粘贴。

功能六：/tests——一键生成单元测试

写测试是好事，但写测试也是苦力活。选中一个函数，输入 /tests：

/tests 给这个函数生成完整的单元测试，覆盖正常输入、边界值、异常情况

它会生成包含 describe/it 结构、mock 依赖、断言覆盖 3 种场景的完整测试文件。

实测：一个 CRUD service 的测试，手写大概 40 分钟，/tests 生成 + 人工微调大概 8 分钟。省下的时间够喝两杯咖啡。

注意：生成的测试代码需要人工审查——Copilot 有时候会对 mock 数据过于乐观，你需要确认边界条件是否真的覆盖到了。

功能七：多建议面板——不止一个答案

默认情况下 Copilot 只显示第一个补全建议，按 Tab 接受。但按 Ctrl+Enter 会打开一个面板，显示 10 个备选方案。

这个功能在处理有多种实现方式的逻辑时特别有用——比如你想写一个排序函数，Copilot 可能同时给出冒泡排序、快排、用 Array.sort() 三种方案，你可以直接选最合适的那个。

小技巧：打开多建议面板后，用 Alt+] 和 Alt+[ 快速切换，不用鼠标。

功能八：内联聊天 Cmd+I——不离开编辑器改代码

大多数人用 Copilot Chat 是打开侧边栏。但其实有个更快的方式：选中代码，按 Cmd+I（Windows: Ctrl+I），会在代码上方弹出一个内联输入框。

直接输入你的需求，比如：

给这个函数加上输入参数校验，空值抛异常
把 for 循环改成 map
提取这段逻辑成一个独立函数，命名为 validateOrder

Copilot 会直接在你的代码位置生成修改，带 diff 预览让你确认。整个过程不需要切窗口、不需要开侧边栏，手不离键盘。

我有一个习惯：所有重构操作都用 Cmd+I 完成，比手动改快太多了。

功能九：文件排除设置——让建议更精准

Copilot 默认会索引项目里的所有文件作为上下文。但这有时候是坏事——它会读到自动生成的代码、第三方库、配置文件，然后给出不相关的建议。

在 VS Code 设置里搜索 github.copilot.advanced，可以配置排除规则：

{
  "github.copilot.advanced": {
    "files.exclude": {
      "**/*.generated.*": true,
      "**/dist/**": true,
      "**/node_modules/**": true,
      "**/*.test.*": true,
      "**/*.spec.*": true
    }
  }
}

配置完之后效果很明显——补全建议的准确率提升不少。因为 Copilot 不会被测试文件里的 mock 数据「带偏」了。

一个小细节：不建议排除 .config. 文件，因为 Copilot 需要从项目配置里理解你的技术栈（比如从 tsconfig.json 知道你用的是 strict mode）。

功能十：自动生成 Commit Message——告别 commit 写作恐惧症

这条可能是最简单的，但也是我用得最频繁的。

写完代码，打开 Source Control 面板（Ctrl+Shift+G），你会看到 staged changes 上方有一个按钮。点一下，Copilot 会分析你的改动，自动生成一条描述性的 commit message。

它生成的格式通常是：

feat: add order export to CSV with date range filter

- Added OrderExportService with CSV generation logic
- Added date range picker to orders list page
- Added download endpoint at /api/orders/export

比「fix bug」「update code」这种敷衍 commit 好一百倍。而且它用的是 Conventional Commits 规范，跟 CI/CD 的语义化版本发布完美配合。

说实话，学会这个功能之后，我再也没手写过 commit message。不是懒，是它确实写得比我好。

功能对比：Copilot Free vs Pro vs Business

并不是所有功能都在免费版里。以下是三个方案的对比：

功能	Free	Pro ($10/月)	Business ($19/月)
代码补全	2000次/月	无限	无限
Copilot Chat	50次/月	无限	无限
@workspace 代理
内联聊天 Cmd+I
多建议面板
自定义指令文件
Commit Message 生成
上下文变量 #file/#selection
组织级策略管理
代码建议不外传训练

一句话总结：如果只是偶尔试试 AI 编程，Free 版够了。但如果你日常写代码，Pro 版的 $10/月是本年度最值的订阅——上面 10 个功能里 8 个都在 Pro 版里。

实战场景：用这些技巧重构一个模块

来一个真实流程演示。假设你要重构一个遗留的用户认证模块：

第一步：在聊天窗口输入 @workspace 这个项目的认证模块有哪些文件？帮我列出所有相关文件——搞清楚范围。

第二步：打开主文件，用 /explain 理解现有逻辑。

第三步：选中要改的函数，按 Cmd+I 输入「把这个函数拆成 validateToken 和 refreshSession 两个独立函数」——内联重构。

第四步：选中断重构后的函数，输入 /tests——生成测试。

第五步：如果测试失败，选中失败信息用 #terminalLastCommand 问「这个测试失败原因是什么？」——快速定位。

第六步：staged 所有改动，点 按钮——自动生成 commit message。

全程不到 15 分钟，手写的话至少 1 小时。

常见问题 FAQ

总结：从「Tab机器」到「AI编程伙伴」

大多数人的 Copilot 使用曲线是这样的：

安装 → 哇 Tab 补全好神奇 → 习惯成自然 → 再也没有探索过新功能。

但如果你花 20 分钟把这些功能过一遍——尤其是 @workspace、#file 上下文变量、Cmd+I 内联聊天、/tests 自动生成测试——你的 Copilot 就不再是「补全机器」，而是一个真正能帮你理解项目、重构代码、写测试的 AI 编程伙伴。

试试看。明天写代码的时候，先用 @workspace 问一个问题，你会回来谢我的。

相关阅读：
VS Code vs Cursor vs Windsurf：2026年AI编程IDE横向评测
VS Code + GitHub Copilot 实战：用内联建议和 Copilot Chat 加速日常编码
Python pip install 报错大全：20个常见错误及修复方法（2026）

GitHub Copilot使用技巧：90%的人不知道的10个隐藏功能（2026）最先出现在编程·投资·科技。

上次我写了一篇「月领5000元退休金需要多少本金」，有人在评论区说：「写得挺好，但100万本金从哪来？」

这个问题太实在了。不是每个人都有100万躺在账户里。大多数人都是从零开始攒的。

所以我拿了纸算了一下。假设你是一个普通上班族，每个月能腾出8000块。不算多也不算少——两口子各出4000，或者单身年轻人省下房租的一部份，都能达到。

把这8000块每个月投到A股红利股里，分红全部再投资（DRIP），不碰不卖，只收息再买。十年后你会看到什么？

我直接给你看结果：

二、10年定投模拟：8000元/月，5.5%股息率

十年投入96万。总资产130万。34.4万是分红再投资白送的——你没多掏一分钱。

第10年时，你每年能收到6.8万分红，折合每月5665元。这个数字已经超过了很多人的月退休金。

三、一张图看明白

左图很直白：蓝色是你的投入，紫色是分红滚出来的收益。刚开始紫色面积小得可怜，到了第6-7年以后，紫色开始发力。

右图更直观：每年分红从5280元涨到67982元，翻了快13倍。而你的本金投入增长一直是一条直线。

这就是复利的本质——不是你有多能赚，是你有多能等。

四、5.5%收益率现实吗？看看市场上有什么

我不是瞎拍脑袋说的5.5%。2026年的A股市场上，稳定分红的标的还真不少：

你不需要全仓一只股票。分散到4-6只，平均5.5%的股息率完全做得到。大银行股每年分红就是一门心思的事，十几年的派息记录一查便知。

关键是你得拿得住。很多人看到股价跌了5%就跑，结果错过了两次分红和复利滚存。红利投资最难的不是选股，是心态。

五、分红花掉 vs 分红再投：20年后的差距

好，现在你有两个选择：

方案A：每个月定投8000，但每年的分红都取出来花了（当加薪补贴生活）

方案B：分红一分不取，全部再投回去

20年后：

多出161万。这就是滚存的威力。

前几年憋着不花钱很难受对吧？但到了第10年，你每年光分红就有6.7万。到第20年，年分红19.4万，折合每月1.6万——这个钱你花都花不完。

所以FIRE的真正秘诀不是「找到一只神股」，而是「早开始 + 不分红再投 + 熬住前10年」。

六、不同工资水平怎么调？

不是每个人都能每月投8000。我把不同投入水平的10年结果也算了：

有意思的发现：不分投入金额大小，分红占比都是26.4%——数学上等比例缩放，结果一样。这告诉我们一个残酷又公平的事实：复利不挑人，它只挑时间。

七、现实中的加速器

上面的模拟假设了「月入不变」。现实中有几个加速器可以让你提前到达目标：

• 工资增长：今年投8000，明年升职了投10000。模拟里没算，但你的实际速度会快很多
• 年终奖一次性投入：年底奖3万，啪一下全买红利股，相当于多跑了4个月的定投
• 打新股/可转债收益：A股打新虽然中签率低了，但中一次就是几千到几万，全投回去
• 股息税优惠：持股超1年，股息税免了——这条我写过单独的分析（持股1个月vs1年，分红税差高达50%）

算上这些加速器，10年130万可能只要7-8年就能达到。

八、FIRE三阶段路线图

把这个思路拉长来看，其实是三个阶段：

到了第三阶段，你完全可以辞职、做自由职业、或者彻底退休。因为每年的分红收入已经覆盖了基本生活开支。你不需要卖一股。

这就是FIRE最妙的地方：你不消耗本金，你只靠它的产出活着。

九、常见问题（FAQ）

十、结语：FIRE不是梦，是每天的选择

我写这个系列写了十几篇了。每一篇都在重复同一个道理：高股息 + 分红再投 + 长期持有 = FIRE。

公式很简单，难的是执行。因为你会被大盘波动吓到，会被朋友晒的短线收益刺激到，会被「房价还要涨」洗脑。但只要你守住这条简单的公式，10年后回头看，你会发现——

那些天天追涨杀跌的兄弟还在原地踏步，你的分红账户已经开始给你发工资了。

如果你还没开始，今天是2026年5月31日。现在就是最好的时候。

郑重声明：本文所有数据和分析仅为个人学习和交流目的，不构成任何投资建议。股票市场有风险，投资需谨慎。文中提到的任何股票代码和股息率数据，不代表买入推荐。每个人的财务状况、风险偏好和投资目标不同，请在做任何投资决策前，咨询持牌专业人士或独立研究。过去的派息记录不保证未来的分红水平。作者对因本文内容而产生的任何投资损失不承担责任。

更多FIRE主题文章：
FIRE本金速算：月领3000/5000/8000/10000需要多少本金？
Yield on Cost才是FIRE的终极答案——每月5000元30年后股息率48.7%
买房收租vs买红利股收息：100万投下去30年差距有多大
高股息FIRE的税务密码：持股1个月vs1年分红税差50%
不上班的第366天：100万红利股每个月给我发工资

高股息FIRE之路：从0开始，每月定投8000元，10年攒出第一个100万红利本金最先出现在编程·投资·科技。

统计周期：2026年5月25日～5月29日（本周最后一个交易日）

本周市场回顾

本周A股三大指数集体回调，但红利指数逆势飘红。市场风格出现明显切换：前期强势的科技成长股获利回吐，资金加速流向高股息防御板块。

本周最大的看点是红利指数（000015）一枝独秀，周涨1.10%，与创业板指-2.11%形成鲜明反差。市场避险情绪升温，叠加十年期国债收益率持续走低（跌破1.6%），”资产荒”逻辑再度强化，高股息标的成为资金避风港。

高股息股票池本周表现

本周高股息标的整体跑赢大盘，银行、煤炭板块表现稳健，高速公路板块稳步上行，火电板块受益煤价下行预期大幅反弹：

本周股息率排行榜（股息率 > 4%）

以下股票均满足： 股息率 > 4% 连续分红3年以上 主营业务稳定，已剔除ST股及业绩暴雷股。

股息率 = 2024年度每股分红 / 最新收盘价 × 100%。数据来源：各公司2024年年报分红预案及腾讯行情实时价格。

本周重点关注

• 华电国际（600027）周涨+4.91%，领涨高股息板块：本周火电板块集体爆发，核心驱动是国际煤价持续回落（纽卡斯尔动力煤跌破100美元/吨）。火电企业度电成本显著改善，市场开始定价2025年H2业绩反转。华电国际作为火电央企龙头，分红能力有望随盈利修复而大幅提升，当前4.50%股息率仍有上行空间。
• 红利指数逆势走强，资金逻辑切换明确：十年期国债收益率跌破1.6%，”资产荒”加剧。在无风险利率持续下行背景下，高股息资产的相对吸引力进一步凸显。本周红利指数+1.10% vs 创业板-2.11%的剪刀差，反映市场风险偏好已从”追逐成长”切换为”追求确定性”。
• 陕西煤业（601225）周涨+4.38%，煤炭板块强势不改：尽管碳中和长期趋势对煤炭构成压力，但短期供需格局依然偏紧。陕西煤业凭借优质低成本矿源，在煤价中枢下移中仍能维持高分红能力，10年连续分红记录+4.20%股息率，安全边际充足。
• 大秦铁路（601006）股息率5.97%榜首，但需关注运量波动：大秦线5月日均运量维持在115万吨左右，低于去年同期水平。尽管股息率居首，但经济下行周期中货运量波动风险不容忽视。建议将其作为组合的”压舱石”而非重仓标的。

投资格言

“买股票就是买公司，买公司就是买其未来现金流的折现。高股息不是选股的理由，可持续的高股息才是。”
—— 沃伦·巴菲特（巴菲特式价值投资哲学）

下周展望

短期策略：

1. 防御为主，高股息持续占优。市场短期缺乏明确上攻动力，创业板PE仍处中高位，资金大概率继续向银行、电力、高速公路等低估值高股息板块集中。
2. 关注股息率”天花板”效应。随着部分高息股价格上涨（如招商银行周涨2.40%），股息率自然回落。需动态评估：当股价上涨使股息率跌破4%时，需警惕追高风险。
3. 警惕周期股陷阱。煤炭、钢铁等周期性高息股需格外关注行业景气度拐点，当前煤价已有松动迹象，避免在周期顶部接盘。

下周重点关注方向：

• 银行板块年报后续分红实施进度（除权除息日临近，可能有抢权行情）
• 动力煤价格走势（若跌破关键位，煤炭高息股或承压）
• 十年期国债收益率变化（继续下行则高股息行情强化）
• 中报预告季来临，关注高息股二季度业绩兑现情况

免责声明：本文仅为个人投资研究笔记，不构成任何投资建议。高股息策略并非无风险——股价下跌可能侵蚀分红收益，个股基本面恶化可能导致分红削减。投资有风险，入市需谨慎。请根据自身风险承受能力和财务状况独立决策。

附：本周高股息板块指数概览

下周同一时间，本神继续为你拆解高股息赛道。保持关注，红利不止。

A股高股息周报 2026-05-30 | 红利指数一枝独秀，资金切换高股息最先出现在编程·投资·科技。

“我们现在的问题是，AI 让写代码快了 10 倍，但部署还是和五年前一样慢。就像你买了一辆保时捷，结果每天开在村口的土路上。”

这个比喻有点糙，但道理不糙。这恰好是 Harness 这家公司这几年一直在盯着的问题——不是”怎么用 AI 写更好的代码”，而是”代码写完之后，剩下的那一大坨事情怎么办”。

先搞清楚 Harness 在做什么

简单说，Harness 做的是软件交付平台。从 CI（持续集成）到 CD（持续交付），从 feature flag 到云成本管理，从安全扫描到混沌工程——一句话，代码从程序员脑子里出来到跑在用户手机上，中间的所有环节，Harness 都想管。

但这只是表面。真正有意思的是他们最近在做的两件事：Context Graph（上下文图谱）和 Agent Loop（智能体循环）。

这两件事，单独看都挺唬人的，但串起来看，你会发现 Harness 在赌一个很大的方向。

AI Velocity Paradox：这个悖论很真实

Harness 的 CEO Jyoti Bansal 在今年 4 月的一篇博客里提了个概念叫 “AI Velocity Paradox”——AI 速度悖论。

什么意思呢？你打开 Cursor 或者 Copilot，一段 prompt 下去，函数写好了，测试生成了，PR 提了。coding 的内循环前所未有的快。但接下来呢？

CI 跑不跑得通？安全扫描过不过？谁审批？部署到哪个环境？出问题了怎么回滚？

你会发现，coding 只占了整个软件交付链条的很小一块。剩下的那些事情——管道、审批、策略、安全、监控——没有一个因为 AI 变快了。

这就是悖论：内循环加速了，外循环还在原地踏步。整体效率不但没提升，反而暴露了交付体系的瓶颈。

Context Graph：把”组织怎么干活”建模出来

大多数公司对”我们的代码怎么被交付的”这个问题，是没有统一视图的。

有人用 Jira 管需求，有人用 GitHub 管代码，有人用 Slack 沟通，有人用 PagerDuty 处理事故。每个工具里都有数据，但这些数据彼此不认识。CI 系统知道一个 build 失败了，但它不知道这个 build 跟哪个 Jira ticket 有关，也不知道是谁在 Slack 里讨论过这个问题。

Harness 的 Context Graph 要解决的就是这个。

它的核心思路很朴素：把所有工具里的事件流抓下来，洗干净，关联到统一的实体模型上，然后拼接成”任务轨迹”，最后聚合成”组织流程”。

举个例子：一个线上事故发生了。SRE 在 Slack 里说了句话，开发在 GitHub 上开了个 PR，CI 跑了一遍，安全扫描标记了一个漏洞，CD 把修复推到了 staging，审批通过后上了生产。整个过程横跨了五六个工具。Context Graph 做的事情就是把这一串事件缝成一条完整的任务轨迹，标注出每个步骤的类型、耗时、涉及的实体。

有了这些轨迹，Harness 就可以回答一些以前没人能回答的问题：

• “一个 hotfix 从发现到上线，典型的耗时要多久？”

• “安全扫描在哪些阶段最容易被跳过？”

• “审批是真在审查代码，还是走形式点个通过？”

更有意思的是，这些轨迹聚合成流程模式之后，就成了 AI agent 的”经验库”。agent 不再需要硬编码的 playbook，而是可以直接查询：”这种情况，历史上大家是怎么处理的？”

Agent Loop 是新的操作系统

Harness 工程团队提出了一个类比，我觉得挺妙的：Agent Loop 就是新一代的操作系统。

• 上下文窗口 = 内存（RAM）。有限的，能装的东西就那么多。

• 工具调用 = 系统调用（syscall）。agent 跟外部世界交互的方式。

• MCP Server / orchestrator = 内核。管理资源访问，执行策略。

• Knowledge Graph / Context Graph = 文件系统。持久化的结构化数据，agent 按需查询。

• Schema 发现 = 虚拟内存。agent 不需要预先加载所有类型定义，用到什么查什么。

如果你接受这个类比，那设计约束就很清楚了：你不能把整个 Context Graph 塞进 agent 的上下文窗口，就像你不会把整个文件系统加载到内存里。 你得提供一套精简的查询原语，让 agent 自己去取它需要的那块切片。

Harness 团队在实践中走到了这一步：他们最开始给 MCP server 设计了 130 多个工具，每个工具对应一个具体的 API 端点。后来发现这根本没法用——agent 面对这么庞大的工具列表，光是选工具就消耗了大量 token。后来他们大刀阔斧地重构，砍到只剩 11 个通用动词（list、get、create、update、execute、describe、diagnose 等），背后靠一个资源注册表根据类型动态分发。

这是一个很有价值的教训：agent 的能力边界不在工具数量，而在后端的可查询性。工具越少越薄，后端越厚越强。

从 CAB 到 Pipeline Governance：审批这件事正在被重新定义

传统软件公司的发布流程里，有一个绕不过去的东西叫 CAB（变更顾问委员会）。一屋子人每周坐在一起，review 一堆变更请求，决定哪些能上线。

本意是好的：找人把关，别让有问题的代码跑出去。

但实际操作中，CAB 有几个致命问题：

• 表面审查。 CAB 成员通常没有深度的上下文，review 的是”证据包看起来齐不齐”，而不是”变更本身安不安全”。

• 批量风险。 变更在周期之间堆积，最后一起上线。发布越大，爆炸半径越大。

• 节奏瓶颈。 交付速度取决于会议频率，而不是团队能力。

Harness 提出的替代方案是自动发布管理：把审批逻辑从会议室搬进管道里。

安全扫描过不了？自动拦。测试覆盖率不够？自动拦。没有定义回滚流程？自动拦。

核心问题的问法变了。旧的模型问的是：”谁批了这个？”新的模型问的是：”这个变更证明了它自己能安全上线吗？”

这里有一个不容易被察觉的转变：治理不是发布的前置条件，而是管道的输出。 合规不是你在发布前要凑齐的材料，而是管道跑完自然就有的东西。

行业变革：软件工程的下一个十年

把以上这些串起来，我觉得 Harness 在赌的是三件事：

第一，软件开发的核心矛盾正在转移。 过去十年，行业在解决”怎么写代码更快”的问题——IDE、框架、云 IDE、Copilot、Cursor，这条线一直在往前推。但未来十年，核心矛盾会转移到”怎么写完之后安全地交付”。coding 加速了，delivery 必须跟上，否则加速没有意义。

第二，交付流程的可观测性会和代码一样重要。 现在做 APM 的公司很多，做代码质量的公司也很多，但做”交付流程质量”的公司还很少。你随便问一个 CTO，你们的代码测试覆盖率是多少，他可能答得出来。你问他一个 PR 从创建到上线平均要多久、瓶颈在哪，他大概率要去翻好几个系统才能给你一个大概的数。Context Graph 要填补的就是这个空白——把交付本身当作一个一等公民来观测和建模。

第三，Agent 不是替代人，是替代”查系统”这件事。 现在工程师花在”查”上的时间可能比”写”多得多——查这个环境配置对不对、查上次是谁改的这个文件、查审批走到哪一步了、查线上为什么报了这个错。这些事情，本质上都是在不同的系统之间跳转、拼凑信息。如果一个 agent 能直接回答”这个 change 历史上出过什么问题”或者”按照类似情况的常规做法，下一步应该怎么走”，那工程师就可以回到真正需要创造力的工作上去。

这也是为什么 Harness 今年推 Cursor 插件这件事值得关注。它不是做另一个 AI coding 工具——市面上够多了。它是在说：你继续用你的编辑器写代码，写完之后的整条交付管道，我来帮你串起来，你在编辑器里用自然语言就能管。 “把这个 PR 部署到 staging，安全扫描过了自动推到 production，出问题了 Slack 我”——这就是 Harness 想让你做到的事情。

但说实话，挑战也不小

Context Graph 这玩意儿好是好，但落地的坑很深。

首先是身份对齐的问题。同样一个人，在 GitHub 里叫 priya@example.com，在 Slack 里叫 priya.k@example.com，在 HR 系统里叫 Priya Kumar (Engineering)。你要是没把这三个身份证明是同一个人，后续所有的流程聚合全是歪的。这件事做起来没有技术含量，但极其吃功夫。

其次是匿名化阈值的把握。流程模式是从个人的工作轨迹聚合出来的。如果某个模式只出现在两三个人身上，那你到底是在建模”组织流程”还是在泄露个人隐私？Harness 团队引用了 Glean 的经验：一个模式至少要出现在 k 个不同用户和 n 条独立轨迹上，才算可信。这个 k 和 n 怎么定，上线之前要想清楚，而不是出了问题再补。

还有语义层的一致性问题。如果你每次接入一个新工具就给它一套临时映射，不用多久，Context Graph 里的查询就会返回矛盾的结果。工程师一旦发现数据不可信，整个系统的价值就归零了。

最后也是最容易被忽略的一点：Context Graph 是会”过期”的。团队会重组，工具会替换，流程会演变。如果一个季度不重新聚合，图谱就变成了博物馆。你以为是活的流程模型，实际上是一个过期的组织架构图。

结尾说点实在的

Harness 的工程博客里有句话我很认可：”我们不是在重新发明图数据库。我们是在把老的系统工程原则——小接口、按需分页、内容寻址存储、反馈循环——应用到一个最近两年才变得可解的问题上。”

这句话挺诚实的。Context Graph 和 Agent Loop 都不是什么天降神兵，它们背后的工程思想存在了很多年。真正不同的地方在于，AI agent 的出现让”建模组织流程并让机器推理”这件事第一次有了明确的消费场景和商业价值。

软件工程这行，每隔几年就会有人说”这次不一样”。但这次可能真有点不一样。不是因为 AI 本身有多神，而是因为 AI 让软件交付链条上那些长久被忽视的”脏活累活”第一次被摆到了台面上，并且有了被系统化解决的可能性。

至于 Harness 能不能成为这个方向的赢家——那是另一个问题了。但至少，它把问题问对了。而在我们这个行业里，问对问题比给对答案更难。

本文基于 Harness 工程博客公开资料、Harness Cursor Plugin 官方公告及 Harness 文档架构分析撰写。

Harness Engineering：当软件交付本身也变成了一行代码最先出现在编程·投资·科技。

先说一个真实感受——我2021年开始研究红利股的时候，最大的遗憾不是「买晚了」，而是「为什么2016年没人告诉我这些」。当时我还在加班改PPT，完全不知道A股里有几只股票，每年往你账户里打的钱一年比一年多，而且已经连续打了十年。

今天这篇，我把A股里真正做到了「连续10年涨股息」的6只股票拉出来，用数据说话：如果10年前投进去10万块，分红再投资，到今天到底变成了多少。

PS：这篇文章里的数字会让你很后悔。但也可能会让你在2026年做出不一样的选择。

凭什么它们是「王者」？三个硬标准

不是所有高股息的股票都值得买。有些公司今天分5%，明年业绩暴雷不分了——这叫「股息率陷阱」。真正值得加入FIRE组合的，必须扛住以下三个标准：

1. 分红从不中断：至少连续10年每年都有分红，没有断过一年
2. 每股分红在增长：不是原地踏步，而是实打实一年比一年多
3. 能穿越牛熊：经历过2015年股灾、2018年贸易战、2020年疫情、2022年熊市，分红照发

按这三个标准筛完A股4000多只股票，剩下的两只手都能数过来。我挑了最有代表性的6只，看过它们的10年分红记录你就知道什么才叫「真·印钞机」。

六大王者10年分红全记录

上图左边是10年累计分红的排行榜，右边是三家最猛的增长轨迹。下面我把每家的核心数据拆开讲：

1. 格力电器（累计分红 ≈ 21.5 元/股）

空调一姐，2016年每股分1.5元，2025年涨到2.5元。十年累计每股分红超过21元。很多人说格力不行了，但你去翻它过去十年的分红记录——没有一年低于1.2元。即便是在疫情最严重的2020年，照样分了2.2元。

关键数据：2016年股价约22元，按买入价算的股息率约6.8%。十年后光分红就回了本，手里股票等于是白送的。

2. 中国神华（累计分红 ≈ 15.75 元/股）

煤炭龙头，非常典型的「闷声发财型」。2016年每股才分0.46元，你敢信？到2022年直接飙到2.55元一股。十年间分红金额涨了4.8倍。2023年略有回落但依然有2.26元。

关键数据：2016年股价约15元，初始股息率约3%。到2025年，按买入成本算的股息率已经超过14%——这就是Yield on Cost的魔力。

3. 招商银行（累计分红 ≈ 14.43 元/股）

银行里的优等生。2016年每股分0.69元，到2025年涨到2.2元，十年翻了3倍多。关键是增长非常稳定，几乎每年都在涨，没有一年倒退。

关键数据：2016年股价约18元，初始股息率约3.8%。十年后股息率按成本算超过12%。这还不算股价本身的涨幅。

4. 长江电力（累计分红 ≈ 7.6 元/股）

水电一哥，稳如老狗。和前面几位不一样，长电的分红增长慢但确定性极高。十年每年都涨一点点，像定时发工资。虽然累计金额不如神华和格力，但它是最让人安心的——不用操心煤价、不用担心竞争，水来了就有电，有电就有钱分。

关键数据：2016年股价约14元，初始股息率约4.3%。十年下来股息率按成本算约6.1%。适合求稳的FIRE族。

5. 大秦铁路（累计分红 ≈ 4.54 元/股）

煤炭运输专线，商业模式简单到无聊：把山西的煤拉到秦皇岛港口。因为太无聊了，所以稳定得可怕。十年里只有2023年略有减少（0.44元），其余年份稳定在0.48元附近。

关键数据：2016年股价约7元，初始股息率约3.6%。到2025年股息率按成本算约7.1%。

6. 工商银行（累计分红 ≈ 2.7 元/股）

宇宙行，虽然每股金额最小，但胜在确定性无敌。从2016年的0.23元到2025年的0.32元，每年稳稳地涨1-2分钱。十年从未中断，从未减少。而且股价便宜，几块钱就能买一股，特别适合定投。

关键数据：2016年股价约4.5元，初始股息率约5.1%。十年后股息率按成本算约7.1%。

10年前投10万，分红再投资，今天变多少？

这才是最刺激的部分。假设2016年1月投入10万元，买其中一只，分红当天立刻用分红金再买入同一只股票（忽略手续费），持有到2025年底不动。以下是推演结果：

注：以上为简化模拟，股价取2016年初近似值，2025年底以近期股价估算。再投资忽略交易费用和税费。实际收益受买入时机、股价波动影响，仅供参考。

什么概念呢？格力电器10万变45万，年化16%。同期存银行定期、买理财、甚至买很多公募基金都跑不过这个数字。

最可怕的是什么——你什么都没做。就是买了，等着，每年收分红，收完继续买。十年之后，10万变45万。

「分红再投资」到底有多猛？拆给你看

很多人只知道「分红好」，但不知道「分红再投资」比「分红花掉」到底强多少。我用招商银行2016-2025年的数据做了一个对比：

看清了吗？同样是招行，分红花掉和分红再投，10年差了18万。这18万多出来的钱哪来的？就是你用分红买的那些股票，它们自己也每年在给你分钱。这就是复利——利润滚利润。

关于分红再投资vs花掉的完整对比，我之前写过一篇更详细的：同样100万买红利股，分红再投资vs花掉，20年后差距让你怀疑人生，可以去看看那个20年的推演，更震撼。

FIRE实战：你需要多少股才能「财务自由」？

说了这么多历史数据，现在聊点实际的：如果你现在开始买这些分红王者，要达到每个月被动收入5000元（覆盖基本生活），需要多少钱？

拿当前的情况来算（数据为近似的参考值）：

看最后两列——月领5000元，最低只需要约84万（买大秦铁路）。如果你能攒到150-200万，分散到两三只王者里，每个月的被动分红就足够覆盖生活开销了。

这个金额比很多人想象的「财富自由需要1000万」要低得多。我之前算过更详细的FIRE本金表：月领3000/5000/8000/10000元退休金需要多少本金，里面还有不同金额的梯度计算。

每月定投5000元，多少年能追上这些10年王者？

好，假设你现在没有100万，只能每月从工资里抠5000块出来定投。按招商银行当前的股息率（约5.4%）和每年分红再投资来计算，推演如下：

假设条件：年股息率5.4%，股息年增5%，分红即时再投资，忽略交易费用和股价波动。

15年，每月5000块定投。到第15年，一年光分红就有8万多，平均每个月6800多元。这个时候你可以选择——继续上班积累更多，或者直接辞职靠分红生活。

这个推演比你想象的靠谱，因为：

• 我们没有假设股价暴涨（只算了分红和再投资的复利效应）
• 我们用的是招商银行当前的股息率和保守的5%年增长
• 实际如果遇到熊市股价下跌，分红再投资能买到更多股，长期更划算

想系统了解定投策略的可以看这篇：高股息FIRE策略：每月定投5000元，20年后财务自由。

这三只如果组合起来呢？

分散是FIRE的铁律。如果你把资金三等分放在中国神华（煤炭+能源）、招商银行（金融）、长江电力（水电），会发生什么？

这三个行业几乎不相关——煤价涨跌不影响银行，水多水少不影响煤炭。拿三只组合做一个简单的10年回测：

三等分组合（2016-2025）

投入30万（每只10万），分红再投资

2025年底市值：约339万（三只合计）

年化收益：约13.8%

2025年分红收入：约17.5万（月均1.46万）

30万变成339万，而且每年还在给你发17.5万的工资。这就是我说的高股息FIRE实战组合——不用赌一只，三只分散，但每只都是王者级别。

别踩「股息率陷阱」——三个判断标准

说完好的，我必须泼一盆冷水。不是所有6%股息率的股票都值得买。以下三种情况是高息陷阱，碰了就掉坑：

1. 一次性高分红：公司变卖资产或一次性收益发的特别分红，第二年就没了。看连续3年以上的分红记录，不要被单一年份迷惑。

2. 利润下滑但硬撑分红：公司业绩在走下坡路，但为了维持股价强行借钱分红。这种公司的资产负债率会飙升，随时可能暴雷。分红率持续高于80%要警惕。

3. 股价大跌导致股息率虚高：比如股价从20元跌到10元，股息率从3%变成6%。这不是捡便宜，是市场在用脚投票。要查清楚背后原因。

真王者不需要这三招——它们的分红来自持续增长的利润，股价虽有波动但长期向上，股息率稳定在合理区间。

FAQ

总结：高股息的终极FIRE逻辑

今天这篇文章的核心就一句话：

高股息 + 复利再投资 + 长期持有 = FIRE

不是选股多厉害——是时间够长。不是本金多大——是复利太猛。不是你比别人聪明——是你比别人有耐心。

A股里那些连续10年涨分红的公司，像格力、神华、招行、长电，它们已经在用行动证明了这个公式。你需要做的只有三件事：

1. 选对标的：不是追热点，是找那些10年没断过分红的真王者
2. 持续投入：每月定投，别管涨跌，也别想抄底逃顶
3. 分红再投：在FIRE之前，把所有分红都买回去，让雪球滚起来

十年后你会感谢今天做了这个决定。

附上这个系列的其他文章，帮你一步步搭建自己的FIRE体系：

• 入门：每月定投5000元，20年后财务自由
• 本金计算：月领3000-10000元需要多少本金
• 对比：买房收租 vs 买红利股收息
• 核心概念：Yield on Cost——股息率会”自动涨”
• 税务必读：持股时间决定分红税率
• 组合搭建：5只红利股月入过万组合

免责声明：本文所有数据和分析仅供参考，不构成任何投资建议。文中提到的股票仅为案例分析，不代表推荐买入或卖出。股市有风险，投资需谨慎。过去的分红记录不代表未来表现。在做出任何投资决策前，请咨询专业的财务顾问。

高股息FIRE之路：A股10年分红王者榜——6只连续涨股息10年的股票，现在回头看傻眼了最先出现在编程·投资·科技。

你有没有遇到过这种情况——VPS 跑着跑着突然服务挂了，一查才发现 /var 分区满了？MySQL 写不进去数据、Nginx 报 500、Docker 容器莫名其妙退出……根因都是磁盘满了。

我刚用 VPS 那会儿就踩过这个坑。WordPress 站点突然打不开，SSH 上去 df -h 一看，/ 分区使用率 100%。当时满脑子「怎么办怎么办」，最后只能删日志、清缓存临时续命。后来升级了 VPS 磁盘，发现新加的磁盘在系统里根本看不到——因为没分区、没格式化、没挂载。

这就是今天这篇文章要解决的问题。我会从头讲 Linux 磁盘管理的完整链路：查看磁盘 → 分区 → 格式化 → 挂载 → 永久挂载，以及进阶的 LVM 逻辑卷管理 + 在线扩容。读完你会发现这玩意儿没想象中那么可怕。

本文基于 Ubuntu 24.04 LTS，大部分命令在 Debian/CentOS/RHEL 上通用，差异处会单独标注。

第一步：查看磁盘信息 — 先搞清楚你有多少盘

在动手之前，先摸清家底。三个命令搞定：

1. lsblk — 最直观的磁盘树状图

$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   50G  0 disk
├─sda1   8:1    0   49G  0 part /
├─sda14  8:14   0    4M  0 part
└─sda15  8:15   0  106M  0 part /boot/efi
sdb      8:16   0  100G  0 disk

sda 是系统盘（已分区），sdb 是刚加的数据盘——100G，赤裸裸一整块，没有分区。这就是我们要操作的对象。

2. fdisk -l — 传统分区表查看

$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 100 GiB, 107374182400 bytes, 209715200 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

确认 /dev/sdb 没有分区表，可以放心操作。

3. df -h — 查看已挂载分区的使用情况

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        49G   38G  8.6G  82% /
tmpfs           1.9G  1.1M  1.9G   1% /dev/shm

82% 的使用率还算安全，但如果超过 90% 就该警惕了。

第二步：传统分区 — fdisk 分区 + 格式化 + 挂载

如果不打算用 LVM（后面会讲），这条链路就是最标准的操作流程。以 /dev/sdb 这个 100G 空盘为例。

2.1 创建分区

$ sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): n        # 新建分区
Partition type: p (primary)    # 主分区
Partition number: 1
First sector: 2048             # 默认
Last sector: +100G             # 或用回车使用全部空间

Command (m for help): w        # 写入并退出
The partition table has been altered.
Syncing disks.

再跑一次 lsblk，你会看到 sdb1 出现了。

$ lsblk /dev/sdb
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sdb      8:16   0  100G  0 disk
└─sdb1   8:17   0  100G  0 part

2.2 格式化 — 创建文件系统

分区只是划了块地，文件系统才是决定「怎么存」的。Ubuntu 上首选 ext4：

$ sudo mkfs.ext4 /dev/sdb1
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: a1b2c3d4-e5f6-7890-abcd-ef1234567890
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done

格式选择建议：

• ext4：最通用，稳定可靠，单文件最大 16TB
• XFS：CentOS/RHEL 默认，大文件性能好，但不支持缩容
• btrfs：支持快照和压缩，适合折腾党

2.3 挂载 — 让系统能访问

$ sudo mkdir -p /data
$ sudo mount /dev/sdb1 /data

$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        98G   24K   93G   1% /data

挂载成功。但有个问题：重启后这个挂载就没了。因为 mount 命令只是临时的。

2.4 永久挂载 — 写入 /etc/fstab

/etc/fstab 是系统启动时自动挂载的配置文件。这一步操作不当会导致系统无法启动，务必小心。

先用 blkid 获取分区的 UUID（推荐用 UUID 而非设备名，因为设备名可能变化）：

$ sudo blkid /dev/sdb1
/dev/sdb1: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"

在 /etc/fstab 末尾追加一行：

$ echo 'UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /data ext4 defaults 0 2' | sudo tee -a /etc/fstab

验证 fstab 是否写对（不会真的挂载，只做语法检查）：

$ sudo mount -a
# 没有报错 = 没问题

重启后 df -h 确认 /data 还在，就大功告成了。

第三步：LVM 逻辑卷管理 — 弹性伸缩的王牌

传统分区有个致命缺点：一旦分好就不能在线扩容。比如你把 /var 分了 20G，半年后满了，要么迁移数据，要么停机重分区——都是一身汗。

LVM（Logical Volume Manager）就是来解决这个问题的。它在你和物理磁盘之间加了一个抽象层，让你可以随时加减空间。

LVM 三层架构

先理解这三个概念，后面的操作就顺了：

• PV（Physical Volume，物理卷）：你的真实磁盘或分区，比如 /dev/sdb1
• VG（Volume Group，卷组）：把多个 PV 合并成一个大池子
• LV（Logical Volume，逻辑卷）：从 VG 池子里切出来的「虚拟分区」

打个比方：你有三块 100G 的硬盘（PV），把它们扔进一个 300G 的大池子（VG），然后从中切出 80G 给根目录、120G 给 home、16G 给 swap（三个 LV）。哪天根目录不够了，从池子里再划 20G 过来，在线扩容，服务不停。

3.1 创建 PV

$ sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.

$ sudo pvs
  PV         VG  Fmt  Attr PSize   PFree
  /dev/sdb       lvm2 ---  100.00g 100.00g

3.2 创建 VG

$ sudo vgcreate vg_data /dev/sdb
  Volume group "vg_data" successfully created

$ sudo vgs
  VG      #PV #LV #SN Attr   VSize   VFree
  vg_data   1   0   0 wz--n- 100.00g 100.00g

3.3 创建 LV

从 vg_data 中切出 30G 作为数据存储卷：

$ sudo lvcreate -n lv_data -L 30G vg_data
  Logical volume "lv_data" created.

$ sudo lvs
  LV      VG      Attr       LSize  Pool Origin Data%  Meta%
  lv_data vg_data -wi-a----- 30.00g

3.4 格式化 + 挂载 LV

$ sudo mkfs.ext4 /dev/vg_data/lv_data
$ sudo mkdir -p /mnt/data
$ sudo mount /dev/vg_data/lv_data /mnt/data

$ df -h /mnt/data
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_data    30G   24K   28G   1% /mnt/data

永久挂载同理，加到 /etc/fstab：

UUID=$(sudo blkid -s UUID -o value /dev/vg_data/lv_data)
echo "UUID=$UUID /mnt/data ext4 defaults 0 2" | sudo tee -a /etc/fstab

第四步：LVM 在线扩容 — 不停机加空间

这才是 LVM 的真正价值。假设 lv_data 的 30G 快满了，VG 池子里还有 70G 空闲。

4.1 扩展 LV

$ sudo lvextend -L +20G /dev/vg_data/lv_data
  Size of logical volume vg_data/lv_data changed from 30.00 GiB to 50.00 GiB.
  Logical volume vg_data/lv_data successfully resized.

4.2 扩展文件系统（ext4）

LV 扩容了，但文件系统还不知道。用 resize2fs（ext4 专用）让它识别新空间：

$ sudo resize2fs /dev/vg_data/lv_data
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/vg_data/lv_data is mounted on /mnt/data; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 7
The filesystem on /dev/vg_data/lv_data is now 13107200 (4k) blocks long.

验证一下：

$ df -h /mnt/data
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_data    50G   24K   47G   1% /mnt/data

30G → 50G，在线完成，服务没中断。注意 XFS 文件系统用 xfs_growfs 而不是 resize2fs。

4.3 如果要缩减空间呢？

ext4 支持缩容，但必须先卸载：

$ sudo umount /mnt/data
$ sudo e2fsck -f /dev/vg_data/lv_data     # 先检查文件系统
$ sudo resize2fs /dev/vg_data/lv_data 20G  # 缩小文件系统到 20G
$ sudo lvreduce -L 20G /dev/vg_data/lv_data # 缩小 LV
$ sudo mount /dev/vg_data/lv_data /mnt/data

缩容有风险，生产环境建议直接加盘而不是缩容——磁盘很便宜，数据丢了哭都来不及。

第五步：实战场景 — VPS 根分区满了怎么办

这是最常遇到的问题。以 Ubuntu 24.04 VPS 为例，根分区 / 满了的排查和解决流程：

5.1 定位大文件

$ sudo du -h --max-depth=1 / 2>/dev/null | sort -hr | head -10
32G     /var
18G     /usr
4.2G    /home
2.1G    /opt
1.5G    /tmp
...

/var 占了 32G，进一步排查：

$ sudo du -h --max-depth=1 /var 2>/dev/null | sort -hr | head -5
28G     /var/log
2.5G    /var/lib
...

/var/log 是罪魁祸首——通常是被 Docker 或 Nginx 日志撑爆的。

5.2 清理日志（治标）

$ sudo journalctl --vacuum-size=500M        # systemd 日志限制 500M
$ sudo find /var/log -type f -name "*.log" -mtime +30 -delete  # 删 30 天前的日志
$ sudo docker system prune -a --volumes     # 清理 Docker 垃圾（谨慎！）

5.3 配置日志轮转（治本）

在 /etc/logrotate.d/ 下创建配置文件，让系统自动压缩和删除旧日志：

$ cat /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 640 root adm
}

5.4 如果还不够 — 扩容 VPS 磁盘

云厂商后台扩容磁盘后，还需要在系统里让分区识别新空间。如果用的是 LVM：

$ sudo pvresize /dev/sda3               # 让 PV 识别扩容后的磁盘
$ sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv  # LV 吃掉所有剩余空间
$ sudo resize2fs /dev/ubuntu-vg/ubuntu-lv  # 扩展文件系统

如果不是 LVM（传统分区），就需要更麻烦的操作——这恰恰说明为什么建议生产环境用 LVM。

第六步：常用命令速查表

常见问题（FAQ）

总结

Linux 磁盘管理的核心就两条链路：

传统路线： fdisk 分区 → mkfs 格式化 → mount 挂载 → /etc/fstab 永久化

LVM 路线： pvcreate → vgcreate → lvcreate → mkfs → mount → lvextend + resize2fs 在线扩容

我个人现在所有 VPS 都用 LVM——曾经半夜两点被 /var 爆满搞过一次之后，就再也不想经历第二次了。花 10 分钟把 LVM 配好，换来的是随时在线扩容的安全感，值。

如果你刚接触 VPS，建议先在虚拟机里练一遍这些命令，搞坏了大不了快照回滚。等你用熟了，这些操作会像 ls 和 cd 一样自然。

推荐阅读：

• Linux crontab 定时任务完全指南 — 用 cron 定期清理磁盘
• VPS 安全加固完整指南 — 配置好磁盘后别忘了安全
• Let’s Encrypt SSL 证书自动续期 — HTTPS 配置一站搞定

Linux磁盘管理完全指南：分区、挂载与LVM扩容实战（2026）最先出现在编程·投资·科技。