staying.fun 有付费内容 支持多语言

staying Code Visualization Platform 是一个在浏览器里逐步执行代码、并把执行过程可视化的平台。它支持 JavaScript、Python、C/C++ 三种语言，输入代码后可以查看当前执行到哪一行、变量取什么值、数据结构如何变化。适合想看清算法执行过程的学习者，以及需要在课堂上演示代码运行过程的教师。它不要求本地安装，打开官网即可开始编写或加载示例。

它能可视化什么

根据官网首页的说明，平台的核心能力是“可执行程序可视化”（EXECUTABLE PROGRAM VISUALIZATION），围绕三个观察维度展开：

• 当前执行行：代码运行到哪一步，哪一行处于活动状态。
• 变量取值：每一步中变量的值是什么。
• 数据结构变化：数组、栈、队列、树、引用关系等结构在执行中如何改变。

这意味着它不只是把代码跑出结果，而是把“过程”本身呈现出来。对于递归、遍历这类靠脑补容易出错的逻辑，逐步观察比只看最终输出更直观。

支持哪些语言

平台明确支持三类语言：

官网关键词中提到了 C++ memory monitor（内存监视）和 JavaScript execution tracer（执行追踪），对应到使用场景，就是观察 C/C++ 程序的内存使用变化，以及一步步追踪 JS 代码的执行路径。

内置示例覆盖哪些典型场景

首页给出了八个可直接加载的示例，覆盖了算法学习中常见的几类结构：

• 01 Recursion（递归）
• 02 Matrix transform（矩阵变换）
• 03 Reconnect references（引用重连）
• 04 First in, first out（先进先出，队列）
• 05 Push characters（字符入栈）
• 06 Traverse a hierarchy（遍历层级结构）
• 07 Key-value lookup（键值查找）
• 08 Breadth-first traversal（广度优先遍历）

以递归为例，官网的描述是：跟随函数进入更深的调用，然后观察每个返回值如何沿调用栈返回。这正是递归最难用静态代码理解的部分——调用栈的进出顺序。

这些示例可以“加载预览”（Load preview），也可以“继续编辑”（Continue editing），也就是说既能直接看效果，也能改成自己的代码再观察。

适合谁用

• 学习者：理解递归、遍历、引用关系、内存变化等抽象概念时，用逐步执行代替凭空想象。
• 教师和讲解者：在课堂或分享中演示一段代码的执行过程，比逐行念代码更清楚。
• 开发者：快速验证一段算法逻辑的执行路径，尤其是涉及数据结构变化的场景。

怎么开始

官网首页提供了两个入口：

1. Start writing code（开始编写代码）：直接输入 JavaScript、Python 或 C/C++ 代码。
2. Read the guide（阅读指南）：先了解平台用法。

也可以从 “Try an example” 加载内置示例，选一个贴近你需求的场景（比如递归或广度优先遍历），先看预览，再点 “Continue editing this example” 改成自己的代码。

需要注意的边界

• 它是一个可视化与追踪工具，定位是帮助看清执行过程，而不是替代完整的本地开发或生产调试环境。
• 官网未在给定资料中说明具体价格与登录要求，是否有免费额度、是否需要注册，需要到官网的 Plans 页面确认后再决定。
• 支持的语言为 JavaScript、Python、C/C++，其他语言不在当前范围内。

如果你的目标是“让代码执行过程变得可见”，尤其是递归、遍历、内存与数据结构变化这类场景，staying 的示例和逐步执行能力可以直接用起来；如果只是想要一个在线编辑器跑出结果，它的价值就不在结果本身，而在过程展示。

JavaScript execution tracer 是一种按执行顺序记录代码每一步状态的工具：它不只像断点那样在某一行暂停，而是把“当前执行到哪一行、变量此刻是什么值、调用栈如何进出”连续呈现出来。它适合用来理解递归、循环、数据结构变化和函数调用关系。如果你只是想让程序停在某处检查现场，普通断点调试就够了；如果你想看清一段代码从头到尾是怎么走完的，tracer 更合适。

execution tracer 和普通断点调试的区别

关键差别在于“连续性”：tracer 把执行过程摊开成一条可回看的路径，而不是只给你几个孤立的暂停点。

用可视化工具追踪 JS 代码的基本流程

以 staying Code Visualization Platform 为例，它的定位是“EXECUTABLE PROGRAM VISUALIZATION”，支持输入 JavaScript、Python 或 C/C++，然后逐步查看当前执行行、变量值和变化中的数据结构。

1. 输入代码：在编辑区粘贴或编写一段 JavaScript。页面提示“Enter JavaScript, Python, or C/C++”。
2. 准备预览：页面会显示“Preview ready when you are”，表示可以加载预览；也可以选择“Continue editing this example”继续修改示例。
3. 逐步前进：加载后按步骤前进，观察“the active line”（当前执行行）如何移动。
4. 观察变量：每一步查看变量值（variable values）的变化。
5. 观察数据结构：注意数组、对象、栈、队列等结构在每一步的形态变化。
6. 查看调用栈：函数调用时看它如何进入更深一层，返回时看返回值如何沿栈传回。

平台内置了多个示例方向，包括 Recursion（递归）、Matrix transform（矩阵变换）、Reconnect references（重新连接引用）、First in first out（先进先出）、Push characters（压入字符）、Traverse a hierarchy（遍历层级）、Key-value lookup（键值查找）、Breadth-first traversal（广度优先遍历）。其中 JavaScript Recursion 示例的说明是：跟随函数进入更深的调用，然后观察每个返回值沿栈传回。这类示例很适合作为第一次追踪的起点。

追踪时最值得关注的信号

• 递归：关注每次调用新增的栈帧，以及返回值逐层回传的顺序。进入和返回是两条方向相反的过程，容易看混。
• 循环：关注循环变量在每一轮的值，以及循环体内数据结构是否被累积修改。
• 数据结构变化：数组的 push/pop、对象的增删键、队列的进出顺序，在逐步视图中比在最终结果里更容易看清。
• 调用栈：函数嵌套调用时，栈的深度变化直接反映执行路径。

常见卡点

• 异步代码：setTimeout、Promise、async/await 的执行顺序与同步代码不同，逐步追踪时可能看到“跳来跳去”的现象，这是事件循环机制导致的，不一定是工具出错。
• 闭包作用域：闭包捕获的是变量引用而非某一时刻的快照，追踪时看到的变量值可能随外层变化而变化。
• 浏览器环境差异：不同运行环境对某些 API 的行为可能不同，追踪结果与在浏览器中实际运行的结果未必完全一致。
• 示例与自写代码的差别：内置示例通常结构清晰、便于观察；自己粘贴的代码如果依赖外部环境或输入，可能无法直接运行。

什么时候该用它

如果你的目标是“看懂这段 JS 是怎么执行的”，尤其是递归、遍历、数据结构操作这类过程性强的代码，execution tracer 比单纯读代码或设断点更直观。如果只是排查一个具体报错，普通调试器可能更快。工具选择取决于你要的是“过程理解”还是“问题定位”。

代码可视化是把程序运行时的状态——当前执行到哪一行、变量取什么值、数据结构如何变化、函数调用如何进出——转成可观察的图形或动画。它适合三类任务：学习算法和递归、排查"结果不对但看不出哪里错"的逻辑问题、快速理解别人写的代码。如果你只是想让代码跑出结果，普通运行就够了；当你需要知道"为什么得到这个结果"，可视化才有价值。

代码可视化到底让什么变得可见

程序执行本身是瞬时的，普通运行只给你最终输出。可视化把中间过程保留下来，通常包括四类信息：

• 执行位置：当前停在源码的哪一行，下一步会跳到哪。
• 变量值：每个变量在这一刻的具体取值，而不是最终值。
• 数据结构变化：数组、链表、树、栈、队列在每一步的形状变化。
• 调用栈：函数如何一层层进入，返回值又如何一层层传回。

以递归为例，这是最难靠读代码想清楚的结构之一。可视化会显示函数进入更深一层调用，然后每个返回值沿调用栈往回传递。staying 平台的示例描述里就用了这个场景："Follow a function into deeper calls, then watch each return value travel back through the stack."（跟随函数进入更深的调用，然后看每个返回值沿栈传回。）这正好对应递归学习中最容易卡住的地方——不是不会写递归，而是想不清返回顺序。

常见的可视化形式

不同工具侧重不同，常见的有这几种：

staying 平台把这几类合在一起：输入 JavaScript、Python 或 C/C++ 后，可以单步查看当前行、变量值和变化中的数据结构。它的示例覆盖递归、矩阵变换、引用重连、先进先出、字符入栈、层级遍历、键值查找、广度优先遍历等，基本对应了数据结构与算法课程里的核心主题。

以 staying 为例：怎么一步步看清执行过程

前提是你有一段可运行的代码，并且清楚自己想观察什么（某个变量、某次递归、某个数据结构的变化）。

1. 输入代码：在平台里输入 JavaScript、Python 或 C/C++ 代码。三种语言的支持意味着你可以用自己熟悉的语言验证同一套逻辑。
2. 选择或加载示例：如果不想从零写，可以先打开一个示例（如递归、广度优先遍历），观察它如何被可视化，再替换成自己的代码。
3. 单步执行：逐步前进，每一步关注三件事——当前停在哪一行、相关变量变成了什么、数据结构形状有没有改变。
4. 对照预期：把你以为会发生的情况和实际显示的情况对比。差异出现的那一步，通常就是 bug 或理解偏差所在。

预期结果是：你能指着某一步说出"这里变量应该是 X，但实际是 Y"，而不是只能看到最终输出对不上。

选择可视化工具时看什么

不用追求功能最多，按你的实际任务挑：

• 语言支持：只写 Python 就不必选只支持 JS 的工具；要跨语言对比，就选多语言支持的。
• 执行粒度：能否单步到每一行，还是只能看整体动画。排查逻辑错误需要前者。
• 是否实时：改一行代码后能否立刻重新观察，还是每次都要重新配置。
• 是否覆盖你要学的结构：学递归就确认工具有调用栈展示；学图算法就确认有遍历动画。

staying 的定位是"可执行程序可视化"，同时面向教学者和开发者，语言覆盖 Python、JavaScript、C/C++，并提供单步、变量追踪和数据结构展示。它页面上有 Plans 入口，具体价格和功能限制需要到该页面确认，本文不代为推断。

常见卡点

• 以为可视化能自动找 bug：它只是把状态摊开，判断哪一步不对仍然靠你。带着"我预期这里是什么"去看，效率才高。
• 代码太长：一次可视化整段程序会淹没重点。把待观察的逻辑抽成一个小函数或最小复现片段。
• 只看不动手：被动看动画容易产生"我懂了"的错觉。每步先自己预测下一个值，再前进验证。
• 忽略数据结构本身：变量值对了不代表结构对。链表、树这类结构要看连接关系，不只看节点值。

C++ memory monitor 指在程序运行时跟踪内存分配、释放与访问行为的工具或机制，核心目标是回答三个问题：内存从哪里来（堆、栈、全局区）、什么时候被释放、有没有被非法访问。它适合排查内存泄漏、越界读写、重复释放，也适合理解指针和动态数据结构的行为。如果你的程序崩溃在 free() 或 delete 附近，或者内存占用随运行时间持续上涨，就属于它的典型使用场景。

C++ 内存监控在监控什么

C++ 没有自动垃圾回收，内存生命周期由代码自己管理，所以监控对象主要是几类区域：

监控手段可以分成两类：一类是运行时插桩，比如重载 operator new / operator delete，在每次分配释放时记录大小和调用栈；另一类是外部工具，比如 Valgrind、AddressSanitizer（ASan），它们通过替换分配器或编译期插桩来检测非法访问。

常见观察手段与适用条件

重载 new / delete 记录分配

在全局作用域重载 operator new 和 operator delete，每次调用时打印地址、大小，并可用 backtrace() 拿到调用栈。优点是零依赖、可嵌入任何项目；缺点是只能看到堆分配，看不到越界访问，且需要自己维护分配表来配对释放。

#include <cstdio>
#include <cstdlib>
#include <new>

void* operator new(std::size_t size) {
    void* p = std::malloc(size);
    std::printf("alloc %zu bytes at %p\n", size, p);
    return p;
}

void operator delete(void* p) noexcept {
    std::printf("free at %p\n", p);
    std::free(p);
}

预期结果是每次堆分配和释放都会输出一行日志。卡点在于：如果程序里混用了 malloc / free，重载不会覆盖它们；另外 C++14 之后还有 sized delete，需要一并重载才能完整配对。

Valgrind 与 AddressSanitizer

Valgrind 的 Memcheck 在运行时模拟 CPU 执行，能检测未初始化读取、越界、泄漏，不需要重新编译，但程序会明显变慢，适合在测试环境跑小规模用例。AddressSanitizer 需要编译时加 -fsanitize=address -g，运行速度快很多，报错时会直接给出出错的文件、行号和调用栈，更适合日常开发。

选择条件可以这样看：需要在不改编译选项的前提下检查已有二进制，用 Valgrind；需要在开发循环里快速定位越界或 use-after-free，用 ASan。

典型问题的表现与排查思路

• 内存泄漏：进程 RSS 持续上涨，Valgrind 报告 “definitely lost”。排查时先看泄漏块的分配调用栈，定位到具体 new 的位置，再检查对应的 delete 是否在所有分支上都执行。
• 越界访问：ASan 报 “heap-buffer-overflow”，给出读写地址和对象边界。重点看数组下标计算和 std::vector 的 operator[]（它不做边界检查）。
• 重复释放：报 “double-free” 或 “attempting free on address which was not malloc-ed”。通常是同一指针被两个所有者各释放一次，或者释放后没有置空又被复用。

排查顺序建议从最小可复现示例入手：先让问题在几十行代码里稳定复现，再逐步加回真实逻辑，这样异常分配点更容易被隔离出来。

用代码可视化平台逐步观察变量与指针

staying Code Visualization Platform 支持输入 C/C++ 代码，逐步执行并查看当前行、变量值和数据结构的变化（来源：staying 平台页面 “See every step in your code”，支持 JavaScript、Python、C/C++）。它适合观察指针指向、引用关系和递归调用栈这类“静态看代码看不出来”的行为。

例如需要理解一段链表反转或递归函数的内存行为时，可以：

1. 在平台输入最小示例代码；
2. 逐步执行，观察每一步的变量值和指针指向；
3. 对照调用栈看递归的进入与返回。

它的定位是理解执行过程，而不是替代 Valgrind / ASan 做泄漏检测——平台资料没有说明它具备堆分配追踪或越界检测能力，所以内存错误的定量排查仍应交给专门工具。

实践建议

• 先用 ASan 编译跑一遍测试用例，拿到第一手的错误位置和调用栈；
• 对怀疑泄漏的路径，用重载 new / delete 或 Valgrind 确认分配与释放是否配对；
• 对指针、引用、递归等逻辑问题，用可视化平台逐步执行，把“内存变化”对应到具体的代码行；
• 始终从最小可复现示例开始，先定位异常分配点，再顺着调用栈向上分析。

Python debugger 是 Python 自带的运行时调试工具，核心能力是在代码执行到某一行时暂停，然后由你控制“下一步执行哪里”，同时查看当前作用域里的变量值和函数调用栈。它适合排查“结果和预期不一致”“不知道哪一步把变量改坏了”“递归/循环到底走了哪条分支”这类问题。最轻量的用法是在代码里插入 breakpoint()，运行后自动进入调试器；如果你用 VS Code、PyCharm 等 IDE，图形化调试器提供同样的能力，只是把命令换成了按钮。

Python debugger 能做什么

调试器不是“自动找 bug”的工具，它给你的是执行控制权和状态可见性：

• 暂停执行：在指定位置停下来，此时程序状态被冻结。
• 逐步执行：一次只走一行、进入函数内部、或跳出当前函数。
• 查看变量：随时打印任意变量、表达式、容器内容。
• 查看调用栈：知道当前函数是被谁调用的、参数是什么、返回值会回到哪里。
• 改变执行路径：临时修改变量值、跳过某段代码、强制返回。

这几点组合起来，就能回答“代码到底是怎么一步步跑到这个结果的”。

两种常用方式：命令行 pdb 与 IDE 图形化

两者底层是同一套机制，选哪个取决于你的运行环境。服务器上跑的程序通常只能用 pdb；本地写代码时图形化更省事。

用 breakpoint() 一步步查看执行过程

前提：Python 3.7 及以上，breakpoint() 内置可用（它默认调用 pdb）。

第一步：插入断点。 在你怀疑出问题的那一行之前加一行：

def total(items):
    result = 0
    for item in items:
        breakpoint()          # 每次循环都会在这里暂停
        result += item
    return result

total([1, 2, 3])

第二步：运行程序。 正常执行 python script.py，程序会在断点处停下，终端出现 (Pdb) 提示符。

第三步：用命令控制执行。 常用命令：

• n（next）：执行当前行，停在下一行；不进入函数内部。
• s（step）：执行当前行；如果这行调用了函数，进入该函数。
• c（continue）：继续运行，直到下一个断点或程序结束。
• p 变量名：打印变量值，如 p item、p result。
• pp 变量名：美化打印，适合字典、列表等结构。
• where 或 bt：查看当前调用栈。
• q：退出调试器。

第四步：观察变化。 在循环里反复按 n，每次用 p result 看累加结果，就能确认“第几次循环开始偏离预期”。预期结果是：你能看到 result 从 0 → 1 → 3 → 6 逐步变化，如果某一步不对，问题就定位到了那一行。

验证方法：把断点放在函数入口，用 s 进入函数，再用 where 确认调用链，最后 c 让程序跑完，对比最终输出是否和手算一致。

调试循环、递归和函数调用

循环：断点放在循环体内，反复 n 并 p 关键变量，观察每一轮的输入输出。如果循环次数很多，可以在断点前加条件，例如只关心某一轮，就用 p 检查后决定是否 c 跳过。

递归：递归的难点是“同一行代码被多次执行，每次的局部变量不同”。用 s 进入递归调用，用 where 看栈帧，你会看到同名函数一层层堆叠。每层用 p 看参数，就能判断是“递归没终止”还是“返回值没正确传回”。

函数调用：用 s 进入被调函数，用 r（return）直接执行到当前函数返回，再用 p 看返回值。这能快速确认“是函数内部算错了，还是调用方用错了返回值”。

常见卡点

• 断点不生效：确认代码真的执行到了那一行（可能被 if 分支跳过）；确认运行的是你改过的文件，而不是缓存或另一个副本。
• 总是进入第三方库：用 n 而不是 s，避免一步步走进库函数；或在 IDE 里设置“仅调试我的代码”。
• 多线程：pdb 一次只能控制一个线程，其他线程可能继续运行，导致状态和你看到的不一致。调试多线程时优先缩小范围、加日志。
• 异步代码：await 会让执行在事件循环中切换，单步跟踪容易跳到不相关的协程。建议在关键 await 前后打日志，或只在确定的协程内设断点。
• 变量名和命令冲突：如果变量叫 n、c、p，直接输入会被当成命令。用 p 变量名 明确打印。

用可视化工具辅助理解执行流程

命令行和 IDE 调试器输出的是文本状态，理解递归、矩阵变换、引用关系这类结构时，光看变量值不够直观。staying Code Visualization Platform 的做法是把 Python、JavaScript、C/C++ 的执行过程可视化：输入代码后，可以逐行步进，同时看到当前执行行、变量值以及数据结构的变化，并提供了递归、广度优先遍历、键值查找等示例。它更适合学习和讲解“代码是怎么跑的”，而不是替代生产环境里的断点调试。如果你已经会用 pdb，但想更直观地看清调用栈和数据结构的演变，可以把它当作辅助观察工具；实际排查线上问题时，仍然以 pdb 或 IDE 调试器为准。