90% 的 Python 开发人员在滥用 Jupyter Notebook？

最近和几个搞数据分析的同事聊天，聊着聊着又聊到了 Jupyter Notebook。有人说 Notebook 是最好的发明之一，有人却说它是项目维护的噩梦。其实我特别能理解这两种观点 —— 因为我自己也经历过从“真香”到“真坑”的全过程。

1. Notebook 为什么会被滥用？

Jupyter Notebook 本来是为探索式编程（exploratory programming）设计的，也就是说，它非常适合那种“边试边看”的工作方式。比如数据分析、模型调参、画图展示这些任务，用 Notebook 太方便了： 写几行代码、Shift+Enter，一眼就能看到结果，爽得不行。

但问题是，太方便了反而让人上瘾。 很多人从数据分析开始写，写着写着 Notebook 就变成了完整项目的主程序，还被拿去部署上线。

结果可想而知：变量全局乱飞、函数重名、代码块重复执行顺序混乱，一旦关掉文件重启环境，整个 notebook 就“炸了”。

最典型的一个现象是：

“昨天还能跑的代码，今天一运行全错。”

这不是 Python 坏，而是 Notebook 的执行模型决定的。Notebook 的执行是状态机式的，每个 cell 执行都会修改当前内存状态，而不是像脚本那样从头到尾重新执行。

举个例子：

a = 10

然后在另一个 cell：

a += 5

你可能又改了上面的 cell：

a = 20

但没重新执行第二个 cell，这时候 a 到底是几？没人知道。Notebook 只会记住最后执行的状态。

所以 Notebook 最大的问题就是：它的状态不可追溯、不确定性太高。

2. Notebook 真正该怎么用？

我后来总结了一个原则：

Notebook 适合做“草稿”，不适合做“作品”。

就像你写论文，Notebook 是你推公式、试算、画图的草稿本，但论文正文要放在 .py 文件、模块化代码里。

比如你在做数据分析的时候，可以这样分工：

• Notebook：做数据探索（EDA）、结果可视化；
• Python 脚本：封装核心逻辑、函数、模型；
• CLI 或服务层：用于生产部署。

我举个简单的例子，比如我们想分析一份 CSV 文件：

import pandas as pd
df = pd.read_csv("sales.csv")
df.head()

在 Notebook 里可以快速画图：

import matplotlib.pyplot as plt
df.groupby("region")["revenue"].sum().plot(kind="bar")
plt.show()

但如果你发现这个分析经常要复用，就应该把逻辑提取出来：

# analysis.py
import pandas as pd
defrevenue_by_region(path):
    df = pd.read_csv(path)
return df.groupby("region")["revenue"].sum()

然后 Notebook 里只需要：

from analysis import revenue_by_region
revenue_by_region("sales.csv")

这样一来，Notebook 就变成了一个“展示层”，代码逻辑依然清晰可维护。

3. 生产环境最怕 Notebook 做“主角”

有一次我们团队接了个外包项目，对方用 Notebook 写了一个机器学习服务。看似跑得挺好，但每次重启都要手动执行十几个 cell，而且有些模型加载顺序还不能错。只要执行顺序换了，预测结果都不一样。

我们后来把整个 Notebook 重构成模块化脚本，问题立刻解决。

生产部署时应该：

1. 把核心逻辑独立成 .py 文件；
2. 把 Notebook 用作调试或报告生成；
3. 把最终可复现流程用 CLI 或 CI/CD 管理。

Notebook 是个好工具，但它不该承载“项目结构”的责任。 你不可能把 app.ipynb 当作系统入口，就像不会用 Excel 写后端服务一样。

4. 一些实用技巧（避免 Notebook 坑）

如果你离不开 Notebook，也有一些技巧能减少坑：

（1）使用 %run 管理脚本依赖

%run ./preprocess.py

这样每次修改 Python 文件，Notebook 执行会重新加载逻辑，而不是依赖旧状态。

（2）清理状态再运行

在菜单栏点击 “Kernel → Restart & Run All”， 确保 Notebook 从头执行，而不是断断续续跑。

（3）用环境隔离

每个 Notebook 对应一个虚拟环境，比如用 conda 或 venv。 不要在系统 Python 环境里到处装包。

（4）版本控制别直接提交 .ipynb

Notebook 文件是 JSON 格式，git diff 看着非常乱。 可以用 nbstripout 去掉输出内容，只保留代码。

pip install nbstripout
nbstripout --install

（5）用 Jupytext

把 .ipynb 自动同步成 .py 文件，既能用 Notebook，又能方便 diff。

pip install jupytext

5. 总结

Notebook 是一把双刃剑。 它让你快速看到结果，也可能让你永远不知道“为什么结果变了”。

所以我经常对新同事说的一句话是：

“Jupyter Notebook 用来思考，不用来交付。”

你可以在它里面“玩”，但最终上线的东西，一定要回到 Python 模块世界。

至于那 90% 的开发者？ 他们不是不会写代码，而是忘了 Notebook 只是工具，不是项目结构的一部分。