marimo 的 run 触发全页反应式重计算，依赖数据流图自动更新；jupyter 的 shift+enter 是命令式顺序执行当前 cell，不回溯清理状态。
marimo 的 run 和 Jupyter 的 Shift+Enter 执行逻辑完全不同
marimo 不是“重新运行当前 cell”，而是触发整页的反应式重计算，依赖数据流图自动推导哪些变量/输出需要更新。Jupyter 是命令式执行：每按一次 Shift+Enter 就顺序执行当前 cell 及其后续依赖（如果手动改过变量），但不会回溯或清理旧状态。
实操建议：
- 在 marimo 中改一个
@app.cell里的输入，所有下游 cell 会自动刷新 —— 你不需要手动点运行，也**不能**靠“只跑这一格”来调试中间值 - Jupyter 里临时加个
print(x)看中间结果很自然；marimo 里得把print写进 cell 返回值，或者用marimo.preview(x) - marimo 的
run按钮本质是触发整个 app 的 re-run，不是 cell-level 控制，所以没有 “Run all above” 这种选项
交互控件绑定方式：marimo 用变量名隐式绑定，Jupyter 需显式调用 interact
marimo 把控件当普通变量用：slider = mo.ui.slider(0, 100) 定义后，直接在任意 cell 里写 slider.value 就能读取实时值。Jupyter 的 ipywidgets.interact 必须把函数和参数显式传进去，控件和逻辑耦合更紧。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 在 marimo 里写了
slider = mo.ui.slider(0, 100)却在另一个 cell 里用slider()（带括号）—— 这会报TypeError: 'Slider' object is not callable - Jupyter 中忘记
display(interact(...))或漏传参数，控件不出现也不报错，容易卡住 - marimo 的控件值变更会触发整个依赖链重算，而 Jupyter 的
interact默认只重跑绑定的函数体，不波及其他 cell
模块导入和全局作用域行为差异极大
marimo 要求所有 import 必须出现在 @app.cell 内，且每个 cell 是独立作用域；Jupyter 的 import 写在任意 cell 都生效，变量默认全局可访问。
性能与兼容性影响：
- marimo 中重复 import（比如两个 cell 都写
import numpy as np）不会出错，但会多做一次解析 —— 实际开销小，但可能误导人以为“可以随便写” - Jupyter 里
import torch后，在下面第 20 个 cell 才首次调用torch.cuda.is_available()，没问题；marimo 中如果这个判断写在没 import torch 的 cell 里，直接NameError: name 'torch' is not defined - marimo 不支持跨 cell 修改全局变量（比如 cell1 定义
state = []，cell2 做state.append(1)），除非用mo.state显式声明
部署和分享场景下，marimo 的单文件 HTML 更轻量，但缺失 Jupyter 的 kernel 生态
marimo 导出为 index.html 后，双击即可打开，所有逻辑、样式、交互全在里面；Jupyter 需要启动 server、依赖 Python kernel、nbconvert 渲染后仍无法交互（除非用 Voilà 或 JupyterHub）。
容易踩的坑：
- marimo 的 HTML 文件里不能执行
!pip install或os.system—— 它压根没 shell 环境，所有代码都在浏览器沙箱里跑（Python 由 Pyodide 编译） - Jupyter notebook 文件（
.ipynb）里写的%matplotlib inline或%load_ext autoreload在 marimo 中完全无效，会直接报SyntaxError - marimo 目前不支持自定义 magic command，也不支持
%%time这类 cell magic
反应式 notebook 的核心约束不在语法，而在数据流是否闭环 —— marimo 强制你画清依赖，Jupyter 允许你绕着走。这点一旦忽略，迁移时 debug 成本会远高于写代码本身。
