PyCryptoBot / 配置参考
config.json 逐项说明：约 30 个真实开关，以及一个反直觉的命名规律
PyCryptoBot 的行为几乎全部由工作目录下的 config.json 决定：交易哪两个币、多久评估一次、买入前要过几道过滤、什么条件下认亏、单笔最多投多少。仓库里给了两份官方样本——config.json.sample 与 config.json.advanced.sample，但没有任何一份文档解释这些键。
这一页把两份样本里的开关按功能分四组抽出来，逐项给出键名、样本里的默认值与你需要注意的地方。开篇先说一个最容易踩的点：买入侧那一批开关叫 disable*，值为 1 表示「禁用这个过滤条件」，也就是把这道关卡拆掉——它和直觉正好相反。
下方所有键名与默认值都来自 2026-09-21 采集的两份样PyCryptoBot 本文件；碰到行为细节，请以官方仓库实现为准。本站不推荐任何具体参数组合，因为参数取决于你的标的、周期与风险预算。
- PyCryptoBot v8.2.4（main=1fa9aaef，2024-03-04）
- Python 3.11（官方 Dockerfile 基线）
- 交易所范围：Binance / Coinbase / KuCoin
- 验证日期 2026-09-21
- 本站未实机运行机器人
config.json.sample 与 config.json.advanced.sample 中出现的真实键名归纳，非官方分类）。四组的含义分别是「什么时候允许买」「什么时候必须卖」「一次买多少」「以什么模式跑和输出什么」。标准样本与进阶样本的区别在哪？
很多人拿到仓库后随手 cp config.json.sample config.json 就开跑。但两份样本的设计意图并不相同：标准样本是「过滤全开、保守买入」，进阶样本把八个买入过滤全部设为禁用，并额外打开动态止损与自定义策略，把判断权交给策略文件。
| 对比项 | config.json.sample（标准） | config.json.advanced.sample（进阶） | 对使用者的影响 |
|---|---|---|---|
| 买入过滤开关 | 只列 7 个，且取值有开有关（disablebuymacd=0、disablebuyobv=1） | 把 8 个全部设为 1，即全部禁用 | 进阶样本等于关掉所有内置买入过滤，买入判断改由自定义策略负责 |
是否含 disablebuyema | 无 | 有（=1） | 均线过滤只在进阶样本里作为可选项出现 |
是否含 buylastsellsize | 无 | 有（=1） | 「按上次卖出的规模买入」是进阶样本独有的仓位控制手段 |
是否含 dynamictsl 与 tsl* | 无 | 有（dynamictsl=1 且带三个 multiplier） | 动态移动止损只在进阶样本里出现，标准样本用的是固定移动止损 |
是否含 enable_pandas_ta / enable_custom_strategy | 无 | 有（均 =1） | 这两个开关是「用 pandas-ta 指标」与「启用自定义策略」的入口，标准样本不含 |
buymaxsize 默认值 | 0 | 10 | 0 表示不限制单笔上限；进阶样本给了一个具体的 10，明显更克制 |
| 计价币种与止损取值 | GBP、trailingstoploss=-1.5、trigger=5 | USD、trailingstoploss=-1、trigger=3 | 样本面向的市场与止损幅度不同，照抄前先改成自己的计价币种 |
是否含 sellatloss / sellatresistance | 两者都有（=0） | 只有 sellatloss（=1） | 「到阻力位卖出」是标准样本独有的一路卖出触发 |
| scanner 段内容 | 含 exchange_bot_count=3、autostart=0、terminal_start_process、maxbotcount=6 | 只含 atr72_pcnt/exitaftersell/enableleverage/use_default_scanner/maxbotcount=5/autosandelay/enable_buy_next | 两个样本的 scanner 段字段并不一致，扫描器的可配置项要按你要用的那份核对 |
| telegram 段内容 | 含 logger_level | 不含 logger_level | 日志级别只在标准样本里出现 |
八个买入侧开关分别是什么？「disable 其实是关掉关卡」是什么坑
买入侧开关的命名规律是：disable + 条件名。值为 1 表示禁用该条件，也就是把这道买入关卡拆掉；值为 0 才表示该条件生效。理解这一点，再看样本里的取值就不会读反。
| 开关 | 类别 | 作用方向 | 适用场景 | 注意点 |
|---|---|---|---|---|
disablebullonly | 趋势过滤 | 限制只在多头趋势中买入 | 顺趋势策略、想减少逆势进场 | 标准样本取 0（生效）。关掉它等于允许逆势买入，回撤结构会明显变化 |
disablebuynearhigh | 位置过滤 | 避免在接近近期高点时买入 | 对追高敏感、想压低建仓成本 | 标准样本取 1（已禁用）。这是样本里少见的「默认关掉一道保护」的地方 |
disablebuymacd | 动量过滤 | 用 MACD 条件约束买入时点 | 想过滤掉动量不足的进场 | 标准样本取 0（生效）。与其它条件叠加时会显著减少交易次数 |
disablebuyema | 均线过滤 | 用 EMA 条件约束买入时点 | 与 MACD 配合做双确认 | 仅进阶样本出现，标准样本里没有这个键 |
disablebuyobv | 量能过滤 | 用 OBV 条件要求量价配合 | 关注成交量确认的策略 | 标准样本取 1（已禁用）。依赖成交量数据质量 |
disablebuyelderray | 强弱过滤 | 用 Elder Ray 判断多空力量 | 想过滤掉弱势反弹中的买入 | 标准样本取 0（生效）。属于较「专业」的一路条件，调参前先理解它的读法 |
disablefailsafefibonaccilow | 兜底过滤 | 斐波那契低点保护 | 防止在极端位置买入 | 标准样本取 1（已禁用）。名字里的 failsafe 说明它是最后一道保护 |
disableprofitbankreversal | 利润回流过滤 | 结合「利润银行」反转条件约束买入 | 不想在利润回吐阶段接盘 | 标准样本取 0（生效）。与卖出侧的利润锁定逻辑相关，建议成对理解 |
卖出侧维度比买入侧更多：17 个真实开关逐项说明
一个容易被忽略的事实：这套PyCryptoBot PyCryptoBot 机器人在卖出与风控上的开关数量远多于买入侧。也就是说，它真正花力气的地方不是「怎么买」，而是「什么时候认亏、什么时候锁住利润、怎么防止把浮盈变成浮亏」。
| 开关 | 作用 | 默认值（取自样本） | 注意点 |
|---|---|---|---|
sellatloss | 允许按亏损卖出，作为一路卖出触发 | 标准 0；进阶 1 | 取 0 时这一路卖出条件不生效，等于不放任亏损离场 |
sellatresistance | 到阻力位即卖出 | 标准 0 | 仅标准样本出现；与「让利润奔跑」的思路相反，需明确取舍 |
selllowerpcnt | 低于买入价达到该百分点时卖出 | 仅进阶 -2 | 与 sellatloss 语义有重叠，同时开启时要想清楚谁先触发 |
trailingstoploss | 移动止损的止损幅度 | 标准 -1.5；进阶 -1 | 负号代表亏损方向；它是「跟随最高点回撤多少就卖」 |
trailingstoplosstrigger | 利润达到多少后开始启用移动止损 | 标准 5；进阶 3 | 只设止损不设触发点，止损会从一开始就生效，容易被正常波动扫出去 |
dynamictsl | 是否改用动态移动止损 | 仅进阶 1 | 取 0 时用固定版；取 1 后下面三个 multiplier 才生效 |
tslmultiplier | 动态止损幅度的倍数 | 仅进阶 1.5 | 仅在 dynamictsl=1 时有意义 |
tsltriggermultiplier | 动态触发点的倍数 | 仅进阶 1.5 | 同上；两个 multiplier 共同决定「多快开始保护」 |
tslmaxpcnt | 动态止损允许的最大回撤幅度 | 仅进阶 -5 | 它是动态机制的封顶值，别和 trailingstoploss 混为一谈 |
trailingsellpcnt | 移动卖出的触发幅度 | 仅进阶 -0.25 | 与移动止损不是同一机制，两者并存时触发顺序要实测确认 |
trailingsellimmediatepcnt | 达到该幅度立即卖出，不等周期收盘 | 仅进阶 -1 | 它会改变成交时点，回测与实盘的差异会因此放大 |
trailingsellbailoutpcnt | 急跌时的兜底卖出幅度 | 仅进阶 -2.5 | 名字里的 bailout 说明它是最后一层保护 |
preventloss | 是否启用「保本卖出」 | 仅进阶 1 | 官方 CHANGELOG 在 5.1.0 引入该选项（防亏损） |
preventlosstrigger | 从多少利润开始盯保本 | 仅进阶 1.25 | 与下一项配对使用 |
preventlossmargin | 回落到多少就执行保本卖出 | 仅进阶 0.5 | 触发后回落即卖，目的是不让浮盈变成浮亏 |
nosellmaxpcnt | 利润率超过该值时先不卖出 | 标准 3 | 用于「涨得太快先观察」的取舍 |
nosellminpcnt | 利润率低于该值时先不卖出 | 标准 -3 | 小幅浮亏不卖，避免被摩擦成本反复消耗 |
一次买多少、以什么模式跑、要不要出图
前三组决定「买不买、卖不卖」，这一组决定「买多少」和「以什么形态运行」。其中 live 与 websocket 两个开关最需要反复确认。
| 开关 | 作用 | 默认值（取自样本） | 注意点 |
|---|---|---|---|
buymaxsize | 单笔买入上限（以计价币种计） | 标准 0；进阶 10 | 0 表示不限制，新手很容易忽略这点而以为「有默认上限」 |
buyminsize | 单笔买入下限，低于该值不买 | 标准 0 | 要与交易所的最小下单量和精度规则配合，否则会出现下单被拒 |
buylastsellsize | 按上次卖出的规模决定本次买入规模 | 仅进阶 1 | 用于保持仓位规模一致，减少规模漂移 |
trailingbuypcnt | 价格回落到该百分比时再买入 | 标准/进阶均 0.5 | 属于「追低买入」机制，避免一次打满；配合 trailingimmediatebuy 系列行为会更复杂 |
live | 实盘开关（0/1） | 标准 0 | 整份配置里最该反复确认的一个。上线前请把它仍然是 0 这件事当作一次单独检查 |
websocket | 是否使用 WebSocket 推送行情 | 标准 0 | 与轮询模式的 API 调用量差别明显；不同交易所的实现成熟度不同 |
autorestart | 异常后是否自动重启 | 标准 0；进阶 1 | 自动重启能救回挂掉的进程，但也可能掩盖真实 bug，使日志更难读 |
graphs | 是否输出图表 | 标准 0 | 依赖 matplotlib；容器镜像里已预设 matplotlib 配置目录，非 root 运行也不会因目录不可写而失败 |
stats | 是否输出运行统计 | 标准 0 | 复盘时有用；与日志一起构成事后核查的主要材料 |
use_sell_fee | 卖出时是否计入手续费 | 标准 1 | 直接关系成本口径，属于「看不出但影响结果」的那类开关 |
manual_trades_only | 只监控不下单，买卖手动执行 | CHANGELOG 6.4.0 引入（样本中未预置） | 适合长期持有但想继续看行情与保证金的场景 |
selltriggeroveride | 信号整体偏强买时抑制卖出触发 | CHANGELOG 6.4.0 引入（样本中未预置） | 官方说明其为自定义策略的配套开关，与点数制策略有关 |
config.json.sample 中，binance 段的 granularity 写的是字符串 "1hour"，而 coinbase 与 coinbasepro 段写的是整数秒 "3600"。同一个字段在同一份文件里出现了两套写法。照抄样本时如果把两种写法混用（例如把 "1hour" 抄到 coinbase 段），很可能配出你意料之外的评估周期。碰到周期行为不对，先核对这里。| 周期枚举值 | 对应的短写 | 含义 | 适用场景 |
|---|---|---|---|
| 60 | 1m / 1min / 1T | 1 分钟 | 高频试水；噪声大、API 调用密集 |
| 300 | 5m / 5min / 5T | 5 分钟 | 短线，对费率与滑点最敏感 |
| 900 | 15m / 15min / 15T | 15 分钟 | 日内波段 |
| 1800 | 30m / 30min / 30T | 30 分钟 | 日内波段，交易次数适中 |
| 3600 | 1h / 1hour / 1H | 1 小时 | 最常见的日内外组合；样本里 coinbase 段用的就是 3600 |
| 21600 | 6h / 6hour / 6H | 6 小时 | 低频，适合不想频繁操作的人 |
| 86400 | 1d / 1day / 1D | 1 天 | 最低频；指标预热需要的历史也最长 |
Invalid Granularity。所以「我想用 2 小时」这种需求在当前实现下没有配置入口——这属于能力边界，不是参数问题。安全改配置的五步：一次只动一个开关
配置类问题的麻烦之处在于「改坏了不报错，只是行为变了」。下面这套顺序的目的是让每一次改动都能被单独归因。
先备份样本，再决定从哪一份起步
命令：在工作目录执行
cp config.json.sample config.json（Windows 用copy），并把原始样本另存一份到别的目录。预期结果：工作目录出现config.json，且你手上还有一份未被修改的原始样本可随时对照。这一步的价值在后面每改一次都体现出来。只改一个开关，并写下改动理由
命令：用编辑器只修改一个键（例如把
disablebuymacd从 0 改成 1），同时在旁边记一行「因为想减少 MACD 条件带来的交易次数」。预期结果：文件仍是合法 JSON——可以用python -m json.tool config.json校验，输出格式化后的 JSON 即表示语法正确。保持
live为 0，以非实盘模式跑一轮命令：先确认
"live" : 0，再按你的运行方式启动（本地python3 pycryptobot.py，或容器docker compose up）。预期结果：日志里出现行情与指标相关输出，且没有任何真实订单被提交。第一次跑务必用最小配置：只配一个币对、一个周期。对照日志确认行为真的变了
命令：查看工作目录下的
pycryptobot.log（compose 场景看挂载出来的宿主文件），搜索买卖决策相关的行。预期结果：你改动的那个条件确实影响了决策路径——如果日志里看不出差异，很可能是改动没被读到（配置文件路径不对、或进程没有重启）。把这次改动记录下来，再动下一个开关
命令：把「改了哪个键、从什么值改到什么值、这次运行的区间、观察到的现象」写进一份变更记录（哪怕是纯文本）。预期结果：当你之后回看某段表现异常时，能回答「那时候的配置是什么」。没有这份记录，所有参数结论都不可复现。
关于配置的高频问题
以下键名与默认值来自 2026-09-21 采集的两份官方样本；行为细节以官方仓库实现为准。本站不推荐具体参数组合。
为什么买入开关都叫 disable*，值还是 1？
因为它们表达的是「禁用某个条件」，不是「启用某个条件」。disablebuymacd: 1 的意思是「把 MACD 这道买入关卡关掉」，而 disablebuymacd: 0 才表示 MACD 条件参与判断。这个命名与直觉相反，读样本时最容易读反。建议做法是：改之前把当前取值抄一行在旁边，改完再抄一行，靠对比而不是靠记。
一份 config.json 能同时跑多个交易所或多个币对吗？
样本的结构是「按交易所分段」，每段各有一套 config（含 base_currency/quote_currency）。所以文件层面可以容纳多家交易所的配置；但一次运行的进程只服务一个币对。要同时跑多个币对，常见做法是准备多个工作目录（各自一份 config.json 与日志），再用 compose 或 systemd 起多个进程——这也是 docker-compose.yaml 里给出了多市场示例的原因。
live 和 websocket 是一回事吗？
不是。live 决定「是否真的下单」，websocket 决定「行情怎么拿」——是轮询还是订阅推送。两者互相独立：可以 live=0 且 websocket=1（用推送行情做模拟），也可以 live=1 且 websocket=0（轮询下单）。上线前请单独确认 live，不要用「我记得改过」来判断。
granularity 到底该写 "1hour" 还是 3600？
两种写法在代码里都能被识别（枚举同时接受整数秒和几种字符串别名，例如 1h、1hour、1H）。真正的问题是官方样本自己在同一个文件里用了两套写法：binance 段是 "1hour"，coinbase 与 coinbasepro 段是 "3600"。照抄时请让一个文件内的写法保持一致，便于排查；具体周期行为以运行日志为准。
两份样本我该从哪一份开始？
建议从 config.json.sample（标准样本）起步：它的买入过滤大部分处于生效状态，便于观察「默认行为长什么样」。config.json.advanced.sample 把八个买入过滤全部禁用并打开自定义策略，属于「把判断权交给策略文件」的形态，更适合已经想改策略逻辑的人。两份都只是示例，不是官方推荐配置。
改了配置文件需要重启吗？
配置是在进程启动时读取的，所以修改后需要重启进程才会生效——具体到 Telegram 控制面，官方还提供了「重新加载配置」类的动作可供使用。判断是否生效最可靠的办法不是看界面，而是看日志：如果行为没有变化，先怀疑配置没被重新读取（路径不对、进程没重启、或改的是另一份文件）。改完记得用 python -m json.tool config.json 校验一次 JSON 语法，语法错误会导致启动直接失败。
disable* 的反向语义、同一份样本里 granularity 出现两种写法），本站按仓库实际写法记录而非按直觉整理。PyCryptoBot 的版本与分支现状见版本页；PyCryptoBot 的交易所覆盖见交易所矩阵页。本站未实机运行 PyCryptoBot。