必须修改c.NotebookApp.autosave_interval参数至合理值（如60000毫秒），写入jupyter_notebook_config.py并重启服务才永久生效；%autosave已弃用，仅临时有效且不适用于新版Jupyter。
默认 120 秒太危险，必须改；但不能无脑设成 5 秒，否则可能卡死页面。
修改 c.NotebookApp.autosave_interval 是唯一可靠方式
这个参数控制前端 JavaScript 定时器的触发间隔，单位是毫秒，写在 jupyter_notebook_config.py 里才真正永久生效。别信“改完就立刻生效”的错觉——它只在下次启动 Jupyter 服务时加载。
- 先生成配置文件（如果还没创建过）：
jupyter notebook --generate-config - 编辑
~/.jupyter/jupyter_notebook_config.py，末尾追加一行：c.NotebookApp.autosave_interval = 60000（即 60 秒） - 重启 Jupyter 服务，新设置才会起作用；刷新网页无效
%autosave 命令只能临时生效，且已弃用
你在 notebook 单元格里运行 %autosave 30，确实会让右上角提示“Autosaving every 30 seconds”，但它只对当前 session 有效，关掉浏览器或重启 kernel 就失效。更重要的是，从 Jupyter 6.0+ 开始，这个 magic 命令已被移除，很多新版环境会直接报错 NameError: name 'get_ipython' is not defined 或静默忽略。
- 别依赖它做生产环境配置
- 它不修改任何后端行为，只是前端 JS 的一次覆盖调用
- 如果你看到文档里还写着这个命令，说明资料已经过期（常见于 2023 年前的教程）
设太短（
自动保存不是“越勤快越好”。Jupyter 每次保存都是全量写入整个 .ipynb 文件（含所有输出、图像、大 tensor），频繁触发会导致：
- 磁盘 I/O 阻塞，页面响应变慢甚至假死
- 浏览器定时器被大量 pending 请求拖垮，最终跳过部分保存动作
- 在远程服务器上，高频率 PUT 请求可能被 nginx 或反向代理限流，返回
502 Bad Gateway而你完全不知情
实测推荐值：本地 SSD 环境设 30000（30 秒），远程云实例设 60000（60 秒）。低于 30 秒的配置，在含 matplotlib 图表或 pandas DataFrame 输出的 notebook 中，大概率引发 UI 卡顿。
别忘了检查点（checkpoint）不是自动保存的替代品
启用 c.FileContentsManager.save_checkpoint（默认开启）只是多存一份 .ipynb~ 备份，但它依赖自动保存成功执行后才生成。如果 autosave_interval 设得太激进导致保存失败，checkpoint 也不会更新。
- checkpoint 不解决“未保存变更丢失”问题，只缓解“文件损坏后恢复”问题
- 它不会记录历史版本，每次覆盖旧 checkpoint
- 真正防丢的核心，还是让
autosave_interval在稳定前提下尽可能短
最容易被忽略的一点：自动保存只在浏览器标签页处于活跃状态时工作。最小化窗口、切到其他 tab、休眠笔记本，都会让前端定时器暂停。所以长实验期间，别单靠它——该 commit 还是要 commit。
