启鑫的黑板报

作者： 启鑫

  • Copy Fail 与 Dirty Frag：Linux Page Cache 提权漏洞中的状态一致性问题

    最近Linux 内核安全研究中出现了两起受到广泛关注的本地提权漏洞：

    • Copy Fail（CVE-2026-31431）
    • Dirty Frag（CVE-2026-43284 / CVE-2026-43500）

    从公开分析来看，两者都属于 Linux Local Privilege Escalation（LPE）类别，但其技术路径并不完全落在传统的 memory corruption 模型中。

    更值得注意的是，它们都指向了同一个方向：

    Linux Kernel 在 Page Cache、Pipe Buffer 以及跨子系统对象生命周期管理中的状态一致性问题，正在逐渐演化为一类新的攻击面。

    传统 LPE 研究通常围绕：

    • use-after-free
    • heap corruption
    • race condition
    • refcount bug

    但近年来的漏洞开始更多涉及：

    • Page Cache consistency
    • splice / zero-copy data path
    • buffer ownership transfer
    • fragment lifecycle transition
    • subsystem state synchronization

    从安全研究与云安全的角度，尝试对这类问题进行更谨慎的结构化分析，而不依赖未完全确认的 root-cause 假设。

    1. 攻击面变化：Page Cache 的角色正在改变

    Linux Page Cache 原本的设计目标是性能优化与 I/O 加速，它横跨多个关键子系统：

    • VFS（Virtual File System）
    • Memory Management
    • Block Layer
    • File Mapping
    • Writeback Mechanism

    在理想模型中，Page Cache 应当满足严格的一致性约束：

    文件内容、缓存视图与权限状态应保持一致。

    但从近年来漏洞演化来看，这一假设在复杂路径下正在变得脆弱。

    以 Dirty Pipe 为代表的一类问题已经证明：

    攻击者可以通过 buffer 语义与内核路径组合，影响 Page Cache 中的只读映射行为。

    Copy Fail 与 Dirty Frag 则进一步将问题扩展到：

    Page Cache 与跨 subsystem 状态同步之间的边界问题。

    2. Copy Fail：Page Cache 写入路径的异常语义

    根据 Microsoft 与 Tenable 的公开分析，Copy Fail（CVE-2026-31431）与 Linux AF_ALG 子系统及 splice() 路径相关。

    漏洞的核心并不在于单一 memory corruption，而更接近于：

    在特定 copy/pipe 组合路径中，Page Cache 写入权限状态被错误继承或误判。

    可以抽象为如下逻辑结构：

    splice(fd, ..., pipefd[1], ...);

/* kernel state: page appears writable under certain conditions */

write(pipefd[1], buf, len);

    利用 splice + pipe buffer 的状态机缺陷，使 write() 误写入 Page Cache，从而实现内核级数据污染或提权

    关键问题不在 syscall 本身，而在于：

    • page ownership state
    • write permission inference
    • pipe buffer semantics

    之间的不一致。

    从结果来看，该类问题可能导致：

    • 文件缓存内容被间接修改
    • 磁盘文件本身未发生变化
    • 传统完整性检测无法直接观测异常

    因此其风险模型更接近：

    Page Cache-based integrity divergence

    而非传统 file overwrite exploit。

    3. Dirty Frag：跨子系统 fragment 状态一致性问题（仍在研究中）

    Dirty Frag（CVE-2026-43284 / CVE-2026-43500）在公开资料中被描述为涉及：

    • ESP/IPSec
    • RxRPC
    • 网络封装与 fragment 处理路径

    相关分析可参考：

    从目前公开信息来看，需要谨慎区分两点：

    已确认部分

    • 漏洞可用于本地提权
    • exploit 不依赖传统 race condition
    • 与 fragment/page 相关内核路径有关
    • 涉及网络 stack 与 memory subsystem 交互

    未完全确认部分

    • 完整 root-cause 机制
    • 是否为单点 bug 或组合条件问题
    • 是否主要来自 refcount / ownership 错误 / state machine error

    因此，更稳妥的研究表述是：

    Dirty Frag 可能反映了 Linux 内核在 page/fragment 生命周期管理中跨 subsystem 状态同步的复杂性问题。

    而不是将其归因于单一类型 bug。

    4. 为什么这类漏洞对云环境影响更显著

    从云安全角度来看，这类 LPE 漏洞的风险模型与传统主机环境不同。

    原因在于：

    现代云基础设施普遍具有以下特征：

    • container 与 host kernel 共享
    • 多租户运行在同一 kernel 上
    • runtime 依赖 namespace/cgroup isolation
    • CI/CD 与 ephemeral workload 大量存在

    因此一旦低权限进程具备 LPE 能力，其影响可能扩展为：

    • Container escape
    • Node compromise
    • Kubernetes workload takeover
    • Multi-tenant isolation bypass

    更关键的是：

    在 Page Cache 类漏洞中，攻击行为可能不会直接修改磁盘文件，因此：

    • 文件完整性检测（FIM）
    • hash-based monitoring
    • 基于落地行为的 EDR

    可能无法完整覆盖攻击路径。

    5. Linux Kernel exploitation 的趋势变化

    从历史来看，Linux kernel exploit 主要集中在：

    • heap corruption
    • use-after-free
    • race condition
    • type confusion

    但随着内核加固机制逐步增强：

    • KASLR
    • SMEP / SMAP
    • refcount hardening
    • allocator hardening

    传统 memory corruption exploit 的成本正在上升。

    与此同时，研究方向逐渐转向：

    • object ownership model
    • lifecycle transition correctness
    • cache coherence assumptions
    • subsystem interaction boundaries
    • state machine consistency

    Copy Fail 与 Dirty Frag 更接近这一趋势，而不是传统漏洞类型的简单延续。

    特别是在：

    • Page Cache
    • splice / zero-copy path
    • pipe buffer semantics
    • fragment handling

    这些复杂路径中，状态一致性问题正在变得更加重要。

    6. 安全运营视角：可观测性问题而非单点漏洞问题

    从安全运营角度来看，这类漏洞的核心挑战不在于“是否已修复”，而在于：

    攻击行为在 runtime 层可能不可见。

    原因包括：

    • 文件未发生变化
    • syscall 行为合法
    • 无明显 persistence artifact
    • 内核层状态异常不反映到用户态

    因此传统检测体系可能需要补充：

    6.1 Runtime telemetry（优先 eBPF）

    • syscall graph tracing
    • kernel function behavior monitoring
    • unusual splice / pipe activity detection

    6.2 容器层隔离强化

    • seccomp profiles
    • minimal capability sets
    • rootless container design

    6.3 高风险路径建模

    重点关注：

    • splice()
    • pipe buffer reuse patterns
    • AF_ALG usage patterns
    • Page Cache write anomaly signals

    7. Copy Fail 与 Dirty Frag 并不只是新增的 Linux LPE 漏洞。

    它们更重要的意义在于：

    Linux Kernel 的攻击面正在从“内存破坏模型”，逐步扩展到“状态一致性模型”。

    尤其是在 Page Cache 与跨 subsystem 交互路径中，传统基于 memory corruption 的安全假设正在被逐步弱化。

    对于安全研究而言，这意味着攻击面正在变得更抽象、更系统化。

    而对于云安全与安全运营而言，挑战也在发生变化：

    问题不再只是“是否存在漏洞”，而是：

    如何在 runtime 层观测到这些“非破坏型状态异常”。

  • AI代码生成安全策略：内网隔离与私有化模型落地指南

    AI代码生成进入企业应用后，安全成核心问题，使用AI快速生成代码已成为现实。但一个随之而来的问题也变得紧迫：生成的代码涉及商业逻辑、客户数据、技术架构，是否应该继续依赖云端模型，还是应该隔离到内网？ 内网隔离和私有化模型不是可有可无的功能，而是企业安全策略的重要组成。与其担心成本，不如从风险角度审视：一次泄露损失远大于长期的架构投资。

    现在的问题不是”要不要用AI生成代码”，而是”如何安全地用AI生成代码”。 这不仅是技术问题，更是关乎企业安全战略的决策。本文基于实践经验，分享我的观察和思考。

    为什么要重新审视AI代码生成的安全性？

    在过去，代码是有形资产，保管在源代码库和服务器里。但AI改变了这一切：

    1. 数据流动的不透明性

    当你将代码片段发送给云端AI模型（如ChatGPT、Claude）来生成代码时：

    • 代码被上传到第三方服务器
    • 可能被用于模型训练（如果未关闭相关选项）
    • 存储在云端的日志中
    • 可能在隐私政策更新时被用于新的目的

    风险：公司的业务逻辑、系统架构、API设计等敏感信息外泄。

    2. 法规遵从的困境

    不同国家和行业有不同的数据保护要求：

    • 欧盟：GDPR对数据跨境传输有严格限制
    • 中国：网络安全法、数据安全法要求重要数据本地存储
    • 金融行业：更严格的信息安全要求
    • 医疗行业：HIPAA等法规对患者数据保护

    3. 竞争情报泄露

    AI模型经过大规模数据训练，理论上可以记忆或推断输入数据模式。虽然开发者声称不会这样做，但：

    • 技术上仍存在风险
    • 合同条款可能变更
    • 子公司可能有不同的政策

    4. 供应链安全考虑

    一旦依赖某个AI厂商，就引入了新的供应链风险：

    • 服务可用性（宕机、限流）
    • 价格变化
    • 政策突变
    • 地缘政治风险

    现状对比：云端vs内网模型

    云端模型（如ChatGPT、Claude）

    优势：

    • 能力最强，模型参数量大
    • 无需本地计算资源
    • 维护成本低
    • 快速迭代，总是最新版本

    劣势：

    • 数据可能外泄
    • 成本随使用量增加
    • 依赖网络连接
    • 无法自定义
    • 法规遵从困难

    私有化蒸馏模型（本地部署）

    优势：

    • 数据完全本地化，无外泄风险
    • 符合各类法规要求
    • 可离线运行
    • 长期成本更低
    • 可针对公司业务优化

    劣势：

    • 需要本地计算资源（特别是GPU）
    • 模型能力较弱（通常比开源模型好，比闭源模型差）
    • 需要技术团队维护
    • 初期部署成本高
    • 需要持续更新

    我的建议方案：分层防御

    基于安全性、成本与工程可实现性，推荐将AI代码生成方案分成三层，形成层级防护策略：

    第一层：云端模型（开放区）

    使用场景：

    • 学习和探索性编程
    • 公开技术讨论
    • 通用工具代码（如数据处理函数）
    • 非敏感算法实现

    操作规范：

    • 允许：通用函数、公开库调用、技术原理咨询
    • 禁止：核心业务逻辑、API密钥、数据库连接字符串、客户数据、架构图

    第二层：私有化蒸馏模型（内网区）

    使用场景：

    • 核心业务逻辑编码
    • 敏感模块生成
    • 涉及客户或企业数据的功能
    • 系统架构与权限控制相关代码

    第二层目标：数据在企业可控网络内流转，避免敏感信息进入公共云。

    第三层：代码审查与合规控制

    不论模型部署方式，都应强制执行：

    1. 不直接上生产：AI生成代码需人工审核
    2. 代码审查：资深工程师复核
    3. 敏感词扫描：自动检测敏感字段（密钥、账号、IP等）
    4. 依赖评估：验证第三方库安全性
    5. 安全审计：定期检查模型调用日志与数据流

    常见疑虑和解答

    Q: 私有化模型的能力会不会太弱？

    A: 这取决于选择。目前的开源模型在代码生成上已经相当不错。虽然不如最强的闭源模型，但对企业内部使用完全足够。关键是合适即可，不必最强。而且私有化模型可以微调，针对公司代码风格优化。

    Q: 我们公司很小，负担不起模型的投入啊？

    A: 有几个选择：

    1. 使用开源模型，租用按小时计费的GPU
    2. 多个公司共享一套私有化部署（虽然涉及信息共享）
    3. 优先保护最敏感的部分，其他部分先用云端
    4. 等待模型成本进一步下降（正在发生）

    Q: 云端模型是否真的会泄露数据？

    A: 根据公开信息：

    • OpenAI、Anthropic都承诺不用对话来训练模型（可选中禁用）
    • 但源代码中的数据依然被传输和储存
    • 即使不主动泄露，也存在被黑客窃取、员工泄露等风险
    • 风险永远存在于数据传输过程

    Q: 团队不愿意放弃ChatGPT怎么办？

    A: 这很正常。建议：

    1. 明确禁止使用ChatGPT处理敏感代码（制度强制）
    2. 为团队提供同样好用的内部替代品
    3. 展示安全事件的案例（激励改变）
    4. 渐进式迁移而不是一刀切

  • 使用AI编码时，应该何时初始化Git？我的实践心得

    最近我开始尝试用Vibe Coding的方式来开发项目，让AI来辅助编写代码。在这个过程中，我遇到了一个看似简单但值得深思的问题：应该等项目成型后再使用Git，还是从第一行代码就开始版本控制？

    • 代码决策的审计日志 – 记录了每一步为什么改动
    • AI优化的实验室 – 安全地尝试不同的Prompt和方案
    • 代码质量的守门人 – 通过commit记录强制你思考每一步的意义

    我的建议：项目第一天就运行git init。 这是我在实践中得出的最重要的经验之一。希望对你的AI编码之旅有所帮助！

    1. 为什么传统开发中人们会犹豫？

    在人工编写代码的年代，很多开发者会觉得：项目还不成熟，加入Git可能显得过度设计。等代码稳定了，功能明确了，再导入版本控制。这个想法在某个时代是可以理解的。

    但AI辅助编码改变了游戏规则。

    2. AI编码的独特挑战

    当你使用AI来生成代码时，出现了一些新的情况：

    2.1 生成质量的不确定性

    AI生成的代码可能一次就很完美，也可能需要多次调整。如果没有Git，你很难分辨哪个版本是有效的，哪个引入了bug。

    2.2 Prompt与代码的对应关系

    当某个功能出现问题时，你想回到某个特定的Prompt执行结果来对比。Git commit的message可以记录当时的Prompt，形成代码和指令的完整链条。

    2.3 实验和分支

    AI可能生成多个不同的解决方案。你想同时尝试不同的实现方式，然后选择最优的。分支管理在这里就变得非常有用。

    2.4 快速迭代的代价

    用AI编码的速度很快，一下子就生成了大量代码。如果中间有问题，往往很难定位改动是在哪一步引入的。频繁的小commit可以精确追踪问题源头。

    3. 我的实践结果

    我采用了以下工作流，效果很好：

    3.1 项目初期

    git init
git add .
git commit -m "Initial commit - project setup"

    3.2 每次AI生成重要代码段后

    git add .
git commit -m "Feature: xxx - AI generated with prompt: [prompt关键字]"

    3.3 AI代码需要修改时

    git add .
git commit -m "Fix: xxx - reviewed and adjusted manually"

    这样做的好处显而易见：

    1. 完整的进化链 – 从Prompt到初版代码，再到最终版本，整个过程都记录在案
    2. 快速定位问题 – 如果某个功能出问题，可以通过git log找到相关的所有commit
    3. 安全的实验 – 敢于尝试新想法，因为随时可以回滚
    4. 代码审查友好 – 使用git diff可以清楚看到每个步骤改动了什么
    5. 团队协作准备 – 即使目前是个人项目，这个习惯为未来团队合作打好基础

    4. 关键点

    4.1 Commit Message要清晰

    一定要在message中标注资源来源：

    • "Feature: xxx - AI generated" – 表示AI生成
    • "Fix: xxx - manual review"– 表示手工调整

    这样回头查看时一目了然。

    4.2 创建.gitignore

    从项目初期就排除不必要的文件：

    node_modules/
__pycache__/
.env
*.log
build/
dist/
.DS_Store

    针对你的项目类型调整即可。

    4.3 考虑创建分支

    对于不确定性较大的功能，创建特性分支尝试：

    git checkout -b feature/experimental-ai-solution
# AI生成代码并测试
git add .
git commit -m "Experiment: xxx"
# 如果成功，合并到main
git checkout main
git merge feature/experimental-ai-solution

    4.4 定期推送到远程

    即使没有团队合作，也建议推送到GitHub或其他平台作为备份：

    git remote add origin https://github.com/你的账号/项目名.git
git push -u origin main

  • 标准化操作为什么重要

    很多团队都在追求效率、质量和稳定，但真正拉开差距的，往往不是某一个人有多强，而是整个团队有没有一套清晰、统一、可复制的做事方式。一个真正成熟的团队，最终拼的从来不是谁更会“救火”，而是谁更有能力把事情稳定地做对、持续地做好。

    很多人一听到“标准化”就会本能抗拒，觉得它意味着流程变多、动作变慢、灵活性下降。可现实恰恰相反。真正成熟的标准化，不是为了束缚人，而是为了减少混乱、降低失误、提升效率，并让团队在人员变化、业务扩张和复杂环境中依然能够稳定运行。

    不标准化短期看似灵活，长期一定会付出质量波动、重复出错、协作低效、培训困难和管理成本上升的代价。相反，长期坚持标准化，带来的不仅是效率提升，更是组织能力的沉淀、风险控制能力的增强，以及团队专业度的持续上升。如果一个团队长期依赖个人经验、临场发挥和口头传达，那么短期看似灵活，长期一定会付出代价。

    什么是标准化操作

    标准化操作，并不是把所有人变成“照本宣科的执行者”，而是把重复性工作中的关键动作、执行步骤、判断标准和交付要求沉淀下来，形成一套大家都能理解、都能执行、都能检查的统一方法。

    它的核心不是“限制每个人怎么做”，而是确保面对同一类问题时，团队能够以大致一致的方式处理，并尽可能得到稳定、可预期的结果。

    简单来说，标准化操作至少要解决四件事：

    • 这件事该怎么做
    • 谁来做，负责到什么程度
    • 做到什么标准才算完成
    • 出现异常时应该如何处理

    当这些问题被说清楚、写清楚、执行清楚，团队的很多问题就会自然减少。

    为什么一定要做标准化操作

    1. 把“个人经验”变成“团队能力”

    很多组织的问题并不是没人会做，而是只有少数人会做。平时靠这些关键人物顶着，似乎一切正常；一旦请假、离职、轮岗，问题就会立刻暴露出来。

    标准化操作最重要的意义之一，就是把原本分散在个人头脑里的经验，转化为组织可以共享、传承和复用的能力。这样一来，工作不会因为“某个人不在”就突然掉链子。

    2. 让执行结果更稳定

    同样一项工作，如果每个人都按自己的理解去做，最后出来的结果一定有差异。有的人做得细，有的人做得快，有的人只完成表面动作，有的人理解重点完全不同。

    标准化的价值，就是把这些“做法差异”尽可能缩小，让执行结果更稳定、质量更可控，而不是每次都靠运气。

    3. 降低错误和返工

    很多错误并不是因为团队不努力，也不是因为能力不够，而是因为没有统一流程、没有检查点、没有明确交付标准。于是一些本来可以避免的问题，最终变成了返工、补救和重复劳动。

    标准化操作的本质之一，就是把常见错误前置拦截，把关键动作固定下来，让团队少走弯路，少付出不必要的成本。

    4. 提高协作效率

    一个没有标准的团队，沟通成本通常都很高。每做一件事，都要反复确认做法、口径、范围和结果要求。很多精力不是花在真正执行上，而是花在解释和对齐上。

    一旦有了统一标准，很多事情就不需要反复问。大家知道该怎么配合、该交付什么、该在什么节点完成，协作效率自然会提高。

    5. 支撑组织规模化发展

    小团队可以靠默契，大团队必须靠机制。

    当业务扩大、人员增加、流程变长之后，如果还停留在“谁懂谁去做”“出了问题再补救”的阶段，组织就很难稳定扩张。标准化不是大公司才需要的东西，而是任何想长期发展的团队都绕不开的基础建设。

    不标准化，短期看灵活，长期代价很大

    很多团队在早期不愿意做标准化，原因很简单: 觉得麻烦，觉得现在还能运转，觉得“先干起来再说”。但问题在于，不标准化带来的成本，通常不是立刻爆发，而是慢慢积累，最后集中体现。

    1. 工作质量忽高忽低

    没有统一标准时，同样一件事今天这样做，明天那样做；这个人做出来是一个结果，换一个人又变成另一个结果。看似大家都在做事，实际上输出质量并不稳定。

    这种不稳定，会直接影响管理判断，也会削弱团队对结果的掌控力。

    2. 同样的问题反复出现

    如果团队没有把经验沉淀下来，就会陷入一种很常见的循环：问题发生一次，解决一次；过段时间又发生，再解决一次。表面上大家一直在处理问题，实际上只是不断重复过去的错误。

    不标准化最大的隐性成本，就是组织没有真正“学会”。

    3. 新人上手慢，交接风险高

    没有标准，新人只能靠别人带、靠自己猜、靠边做边学。这样的培养方式效率低，质量也不稳定。岗位交接时尤其危险，因为很多关键细节根本没有被明确记录下来。

    结果往往是：人虽然换了，工作却很难平稳接住。

    4. 管理越来越累

    没有标准，管理者就只能靠盯、靠催、靠经验判断。很多时候不是团队不会做，而是每个人理解不一样，导致管理动作必须一遍遍重复。

    表面上是执行问题，本质上往往是标准缺失问题。

    5. 组织容易形成“关键人物依赖”

    这类团队通常有一个明显特征：总有几个人特别忙，也总有几个人不可替代。一旦这些人不在，很多工作就推进不下去。

    这不是因为他们太重要，而是因为组织没有把方法沉淀成标准，导致能力长期停留在个人身上，而没有真正变成团队资产。

    长期坚持标准化，到底能带来什么

    标准化真正的价值，往往不是一两周就能看出来的，而是在半年、一年甚至更长时间里逐渐体现出来。

    1. 组织能力会持续沉淀

    长期标准化，不只是把动作固定下来，更重要的是把正确的方法、有效的经验和踩过的坑逐步沉淀下来。时间越久，这套体系就越成熟，团队的执行基础也会越稳。

    这意味着组织不再总是“从头开始”，而是在不断站在过去经验的基础上往前走。

    2. 效率提升会越来越明显

    很多人觉得标准化前期要花时间，所以误以为它会拖慢效率。但从长期看，标准化带来的不是局部提速，而是整体效率的持续提升。

    因为一旦沟通变少、返工变少、培训变快、交接变稳，团队的整体运转就会越来越顺。

    3. 风险控制能力更强

    标准化意味着关键动作有流程、关键节点有检查、关键岗位有交接、关键数据有留痕。这样的机制会显著提升团队应对突发事件、人员变动和业务波动的能力。

    真正成熟的团队，不是“平时很能干”，而是遇到变化时依然不乱。

    4. 更容易做持续优化

    如果每个人做法都不一样，就很难比较到底哪种方式更好，也很难总结哪里该优化。只有先把动作和标准统一起来，优化才有真实基础。

    所以，标准化从来不是僵化的代名词。恰恰相反，标准化是持续改进的前提。

    5. 团队专业形象会越来越强

    标准化程度高的团队，通常会给人一种很明显的感受：事情更稳、反馈更快、协作更顺、失误更少。

    这种专业感，不只是内部管理的收益，也会直接影响客户、合作方和管理层对团队的信任。

    推动标准化落地，关键不是“写文件”，而是真能执行

    很多团队也做标准化，但效果不好。原因往往不是方向错了，而是停留在“写了一份流程文件”这一步。

    如果标准化只停在文档里，它就只是材料，不是能力。

    真正有效的标准化，通常有几个共同点：

    • 先从高频、易错、影响大的工作入手
    • 标准写得足够具体，避免空话和口号
    • 让流程贴近真实工作场景，而不是脱离实际
    • 设置必要的检查点，确保执行不是流于形式
    • 根据实际问题持续更新，而不是写完就不再维护

    标准化最怕两件事：

    • 只有文件，没有执行
    • 只有流程，没有优化

    所以，标准化不是“一次性工作”，而是一种长期管理能力。

  • Docker 磁盘爆满实录：我以为镜像删干净了，结果系统还是报 No Space

    执行了 docker rmi，为什么磁盘空间还是 100% 占用？记录了一次服务器磁盘爆满的排查过程，深度解析 Docker 分层存储与构建缓存，并分享真正有效的深度清理命令。

    在日常开发和运维中，我习惯于用一个简单的命令来清理 Docker 镜像：

    docker rmi <IMAGE_ID>

    删除不再使用的镜像，释放磁盘空间，逻辑看似完美。直到有一天，我的服务器直接弹出令人绝望的红字：

    No space left on device

    我删光了所有能删的镜像，为什么磁盘还是满的？

    1. 现象：镜像删了，空间没回？

    当我意识到磁盘报警时，第一反应是检查 Docker 的占用情况：

    docker images  # 查看镜像列表
df -h          # 查看系统磁盘状况

    诡异的现象出现了：

    • docker images 列表里只剩下几个业务镜像，加起来不到 2GB。
    • 但 /var/lib/docker 目录依然占用了 40GB+。

    这时候我才意识到：看到的“镜像”，并不代表 Docker 占用的全部空间。

    2. 分析原因：为什么 docker rmi 会失效？

    理解这个问题，必须看清 Docker 的底层存储机制。Docker 镜像并非一个独立的文件，而是像乐高积木一样层层堆叠的（Layer-based Filesystem）。

    2.1 镜像层（Layers）的“幽灵”

    当你用 docker rmi 删除一个镜像时，Docker 只会尝试删除该镜像特有的层。如果某些层被其他镜像引用，或者是构建过程中的中间层，它们就会留在磁盘上，变成无法通过 rmi 直接删除的“幽灵空间”。

    2.2 虚悬镜像（Dangling Images）

    在多次执行 docker build 后，旧的镜像会失去标签（Tag），变成 <none>:<none>。这些镜像往往不会出现在你常规的清理视线里，但依然实打实地占据空间。

    2.3 构建缓存（Build Cache）

    这是最隐形的“空间杀手”。特别是开启了 BuildKit 后，Docker 会产生大量的构建缓存。这些缓存完全不会显示在 docker images 列表中，却是磁盘爆满的元凶之一。

    3. 真正救命的命令：docker image prune

    当我发现手动删除（rmi）无能为力后，我使用了 Docker 官方提供的“深度清理”命令：

    docker image prune -a

    这条命令到底做了什么？

    1. 所有未被容器使用的镜像（即使它有 Tag）。
    2. 所有虚悬镜像（Dangling Images）。
    3. 所有孤立的镜像层。

    ⚠️ 安全提示： 只要你的业务容器正在运行，它所依赖的镜像就是安全的，不会被 prune 误删。但对于已经停止（Exited）的容器，其对应的镜像可能会被判定为“未使用”而被清理。

    执行后，我的服务器磁盘占用瞬间从 100% 降到了 15%。

    4. 进阶技巧：如何精准定位与排查？

    在盲目清理之前，我建议先用以下命令定位 Docker 的真实磁盘占用：

    docker system df

    输出会清晰地展示四类数据的占用分布：

    • Images: 镜像
    • Containers: 容器（包括日志和可写层）
    • Local Volumes: 本地卷
    • Build Cache: 构建缓存

    如果 image prune 仍不足以释放空间，可以使用终极命令：

    # 清理一切：停止的容器、未使用的网络、未使用的镜像和卷
docker system prune -a --volumes

  • LM Studio 本地大模型教程：VS Code 使用 Claude Code 实现本地 LLM 调用与部署

    通过 LM Studio 的 Anthropic‑兼容本地服务，将本地 LLM 模型与 Claude Code 集成，使用户能够在 VS Code 或终端 中直接调用本地部署的语言模型进行交互。实现与本地模型的对接。支持更大的上下文长度、流式输出和函数调用等高级功能

    1. 环境说明

    • 操作系统：Windows 11
    • 本地模型工具：LM Studio
    • 编辑器：Visual Studio Code
    • VSCode 插件：Claude Code

    2. 安装 LM Studio

    2.1 下载并安装

    1. 访问 LM Studio 官网，下载 Windows 版本安装包。
    2. 安装完成后启动 LM Studio。
    3. 在“Models”页面下载大模型，例如：
       openai/gpt-oss-20b

    2.2 开启 Developer Mode（本地 API 访问）

    1. 打开：
       Settings → Developer → Local Server
    1. 设置监听地址：
       http://localhost:1234
    1. 启动 API Server，确保浏览器或 VSCode 可以访问：
       http://localhost:1234

    2.3 加载模型

    1. 点击 Load Model。
    2. 选择模型：
       openai/gpt-oss-20b
    1. 设置模型参数：
    • Context length：100000
    • GPU Offload：16 （根据显存大小调整）

    ⚠️ 注意：20B 模型对显存要求高，建议显卡显存≥24GB，或者使用 CPU Offload 功能。

    3. VSCode 配置 Claude Code

    3.1 安装插件

    1. 打开 VSCode。
    2. 扩展市场搜索：
       Claude Code
    1. 点击安装。

    3.2 配置环境变量

    1. 打开命令面板：Ctrl + Shift + P
    2. 输入：
       Preferences: Open Settings (JSON)
    1. 添加以下配置：
    {
    "workbench.colorTheme": "Experimental Light",
    "claudeCode.preferredLocation": "panel",
    "claudeCode.environmentVariables": [
        {
            "name": "ANTHROPIC_BASE_URL",
            "value": "http://localhost:1234"
        },
        {
            "name": "ANTHROPIC_AUTH_TOKEN",
            "value": "lmstudio"
        }
    ]
}

    3.3 测试连接

    1. 在 VSCode 中打开 Claude Code 面板。
    2. 尝试发送一条简单的指令，例如：
       Hello
    1. 如果能正确返回结果，说明 VSCode 已经成功连接到本地 LM Studio 模型。