PTrade策略重启以后，之前的变量是不是还在，不能简单回答“都在”或“都不在”。更准确的说法是：平台会对一部分可持久化内容进行保存和恢复，但不是所有变量都能保存，恢复顺序也可能让新手产生误解。

先理解为什么需要持久化。策略运行时，很多状态只存在内存中，例如今天是否已经下过单、某只证券已经持有几天、上一次信号是什么。如果服务器维护、环境重启或策略重新拉起，单纯的内存变量会消失。为了让策略继续运行，PTrade框架会保存部分股票池、账户信息、订单信息以及全局变量g中的内容。

按照PTrade API说明，框架会在before_trading_start、handle_data和after_trading_end等事件之后触发持久化信息的更新和保存。环境恢复时，会先执行initialize，然后再恢复持久化内容。这个顺序非常关键：如果initialize里把g.flag重新设为False，而持久化数据里保存的是True，恢复完成后，旧值可能覆盖初始化值。

这也是很多人看到“明明initialize里重新赋值，为什么重启后还是原来的状态”的原因。并不是initialize没有执行，而是它执行后，平台又把保存的数据恢复了。对于需要延续的状态，这是好事；对于希望每次启动都重新创建的对象，就要采用不同处理方式。

哪些变量通常可以保存？整数、浮点数、字符串、列表、字典等能够被pickle序列化的常见对象，更适合放在g中持久化。哪些通常不能直接保存？打开的文件、网络连接、线程、某些复杂类实例和依赖外部资源的对象。这类内容即使放进g，也可能无法被正确序列化。

PTrade文档还说明，以双下划线开头的g变量被视为私有变量，持久化时不会保存。例如把某个无法序列化的类实例放在g.__client中，策略重启后需要在initialize里重新创建。这个设计很实用：需要延续的状态放普通g变量，需要每次重建的资源对象使用私有变量。

举个常见例子。假设策略设置g.has_order，用来表示今天是否已经发过订单。如果它被持久化，服务器短暂重启后仍能记住已有订单，避免再次提交。反过来，如果这个变量没有被保存，initialize又把它设为False，重启后handle_data可能再次满足条件，造成重复委托。

但这里不能得出“只要把所有东西都放进g就安全”的结论。真实交易状态仍然应以账户查询为准。订单可能在策略中断期间成交、部分成交或撤销，仅靠g.has_order无法说明真实账户发生了什么。重启后更稳妥的做法，是重新查询资金、持仓、当日委托和成交，再根据柜台状态修正策略变量。

还有一个容易忽视的问题：initialize和before_trading_start可能在服务器恢复时再次执行。如果把下单代码直接写在这些函数里，重启时可能重复执行。PTrade提供了与重启行为相关的配置项，用来减少交易时段重复初始化或重复盘前调用，但新手更应该从代码结构上避免在初始化阶段直接提交无条件委托。

如何判断某个变量是否应该持久化？可以问三个问题。第一，它是否代表需要跨重启延续的业务状态，例如持有天数；第二，它能否被pickle正常序列化；第三，它能否通过账户或数据重新计算。如果能从真实账户重新查询，优先查询往往比完全依赖旧变量更可靠。

测试也很重要。不要等到真实运行中遇到服务器重启才验证。可以在模拟环境里设计一个简单变量，让它在handle_data中累加，停止并重新启动策略后观察值是否恢复；再测试一个双下划线变量，确认它会在initialize里重新创建。通过这种小实验，能直观看懂平台机制。

所以，PTrade变量重启后“还在不在”，关键不在变量名字，而在是否进入平台持久化、是否可序列化、恢复顺序如何，以及策略是否用真实账户重新校验。理解这四点，比死记一个结论更有用。

如果你的策略重启后出现重复下单、持有天数归零，或者initialize中的值被旧值覆盖，可以先检查变量是否放在g中、是否能够序列化，以及恢复后有没有重新查询账户。主页会继续整理PTrade持久化和重启排查案例。本文仅用于量化软件机制说明，不构成投资建议。