工程实践 on Zampo Blog

你的 Docker 镜像为什么有 2GB：从 Namespaces 到 Dockerfile 最佳实践

Thu, 23 Apr 2026 20:00:00 +0800

凌晨三点，线上容器启动要三分钟。

你登上服务器，docker images 一看：2.1GB。PM 问为什么这么慢，你说"容器已经很快了"。

但容器不是虚拟机。你把 Docker 当 VM 用，它当然慢。

问题不在 Docker，在你没理解它到底是什么。

很多人以为 Docker 只是把代码和依赖打包进一个盒子，但依然不知道为什么上了生产就崩。你可能正在给一个简单的 Node.js 应用构建 2GB 的镜像，硬编码环境变量，容器启动要三分钟。

容器不是虚拟机。 它不需要 hypervisor，不需要臃肿的 guest OS。它是一个与宿主机内核直接共享的进程。

看完这篇，你能写出高效 Dockerfile，不再把容器当虚拟机用。

一、容器 vs VM：为什么你的镜像这么大

虚拟机通过 hypervisor 模拟物理硬件。每个 VM 运行独立的操作系统和应用。

VM 有三大痛点：

痛点	表现	后果
资源税	每个 VM 都带着完整的内核	10 个 VM 就是 10 份 Linux 内核，内存和 CPU 大量浪费
启动延迟	启动一个完整操作系统需要几分钟	微服务时代根本等不起
体积庞大	VM 镜像通常几个 GB	存储和传输都很慢

Docker 虚拟化的是操作系统，不是硬件。容器共享宿主机内核，只隔离用户空间的进程、库和依赖。

容器优势：

快：通常秒级启动
轻：不需要独立 OS，内存和 CPU 占用小
可移植：应用和依赖打包在一起，任意环境一致运行

我用 PostgreSQL 替换了整个技术栈，省了 6 个微服务

Fri, 17 Apr 2026 20:00:00 +0800

现代软件工程已经基本变成了"订阅管理模拟器"。

我们被云厂商洗脑了，以为即使构建一个基础应用，也需要拼凑一个脆弱的分布式网络：

Redis 做缓存
Confluent Kafka 集群做后台任务
Elasticsearch 只是为了一个简单的搜索框
再搞个专用向量数据库为了那个临时加上的 AI 功能

等你终于把应用部署给你那"要求极高"的用户群（你自己和你妈）时，你已经欠了十几家 Y Combinator 支持的 SaaS 初创公司的钱，就为了让灯亮着。

这是一个过度工程化、价格离谱的陷阱。

但如果我告诉你，你可以把那些闪亮的云依赖全部扔进焚化炉，用一个经过 30 年验证的开源软件替换它们呢？

科技行业不想让你知道的秘密：一个久经考验的工具可以吞噬你的整个架构。

我刚刚用 PostgreSQL 替换了整个技术栈。

一、PostgreSQL 为什么能吞噬整个栈

PostgreSQL 是一个开源对象关系数据库系统，已经活跃开发了 30 多年。

开箱即用的能力：

坚如磐石的 ACID 合规性——当你的廉价云服务器崩溃时，用户数据不会损坏
可扩展性——这才是它能吞噬整个栈的真正原因

PostgreSQL 不只是行列存储。

它还能存储：

JSONB（半结构化数据）
向量（AI 嵌入）
全文搜索索引
地理空间数据（PostGIS）
图数据（关系遍历）
时间序列数据
键值对（作为 Redis 替代）

PostgreSQL 不是数据库，是一个数据平台。

二、实战替换：Redis（缓存 + 键值存储）

传统架构

应用 → Redis（缓存） → PostgreSQL（持久化）

问题：

两个服务要运维
缓存和数据库数据可能不一致
Redis 挂了要处理降级

PostgreSQL 方案

使用 UNLOGGED 表做高速缓存：

99% 的开发者不懂堆内存，你真的懂吗？

Fri, 17 Apr 2026 18:00:00 +0800

1
2
3
4


func example() *int {
 x := 42
 return &x
}

问你一个问题：这个 x 是在堆上还是在栈上？

如果你答"栈上"，你错了——至少在这段代码里，Go 编译器会把 x 分配到堆上。

为什么？因为它的地址逃逸了函数。

99% 的开发者不懂堆内存——不是不懂 malloc 和 free，是不懂分配器、碎片化、逃逸分析、GC 代价这些让堆变得迷人的底层细节。

你可能觉得内存管理就是"分配"和"释放"这么简单，也可能不在意这些底层细节。但如果你不懂我刚才说的那些术语，或者想深入了解堆内存，这篇就是为你写的。

一、堆 vs 栈：核心差异在哪

先说结论。

栈内存是程序内存中用于存储局部变量的区域，堆内存是用于动态分配的区域。

听起来简单，但 99% 的开发者忽略了两者的本质差异。

差异点	栈（Stack）	堆（Heap）
管理方式	后进先出（LIFO），编译器自动管理	运行时管理，分配器或 GC 管理
分配速度	极快，编译器确切知道值存储在哪里、存活多久	慢，涉及元数据、可能的线程同步、GC
生命周期	函数结束时自动释放	可以比创建它的函数活得更久
大小限制	相对较小，通常几 MB	更大、更灵活，可向 OS 请求更多
碎片化	无	有，频繁分配释放会产生碎片

栈的工作方式：

每次函数调用都会压入一个帧（frame），包含局部变量，返回时弹出。这个过程是严格的后继先出，所以极快。

堆的工作方式：

堆是一个更灵活但代价更高的空间。当程序运行时需要按需分配内存——比如那些可能比当前函数存活更久的对象，或者大小可以增长的集合——堆就是这些内存的来源。

关键区别在于生命周期： 栈变量在函数结束时消失，但堆对象可以比创建它的函数活得更久。

你每天都在用 Git，但你可能不懂 rebase

Tue, 14 Apr 2026 16:10:00 +0800

你在 feature 分支上写了三个提交，准备提 PR。

同事说：先 rebase 一下 main，把历史整理干净。

你照做了，但心里没底：rebase 到底改了什么？会不会出问题？

很多开发者对 rebase 的理解，停留在"会敲命令，不知道它到底做了什么"。