同一个 ord 命令，有时你加了参数不生效、有时删了配置文件行为却变了——ord 官方 Settings 页面把”到底听谁的”写成了一条严格的四层优先链，弄清楚它，配置文件制造的怪现象基本都能当场定位。
规则本身只有一句话：命令行参数优先于环境变量，环境变量优先于配置文件，配置文件优先于内置默认值。文档给了命名换算规则：命令行上叫 —setting-name 的设置，对应环境变量 ORD_SETTING_NAME（连字符换成下划线并全大写），对应配置文件里的字段名 setting_name。举文档自己的例子，数据目录可以用 —datadir 传、可以用 ORD_DATA_DIR 环境变量设、也可以在配置文件里写 data_dir 字段——三种写法殊途同归，但生效的是优先级最高的那一个。
配置文件怎么被找到，文档写了三条路径。用 —config 直接指定文件路径，文件不存在时 ord 直接报错，这是三条里唯一”指名道姓不许缺席”的；用 —config-dir 或 —datadir 指向一个目录，ord 会在里面找名为 ord.yaml 的文件，找不到不算错误、静默走默认；三者都没给时，如果默认数据目录里恰好有一个 ord.yaml，它会被自动加载。最后这条最容易被忽略——很多”我没配置过为什么行为不对”的案例，就是曾经某次运行留下了一个自己都不记得的 ord.yaml，把当时的临时参数固化成了永久默认。
核对当前生效值的方法是 ord settings 命令，文档说明它把 ord 此刻的完整配置以 JSON 打印出来。调试哲学由此非常干脆：怀疑环境问题时，先跑 ord settings 看 JSON 里每个键值，再对照你的预期——值不对，说明某一层覆盖了你的意图；值对而行为不对，才需要怀疑版本或索引状态。相比翻 shell 历史、找 yaml、猜继承关系，一条命令给出真相。
文档同一页面还解释了”隐藏铭文内容”的配置（浏览器端展示过滤的设置入口），提醒自托管者：你的 ord server 显示的隐藏清单来自本机配置，别人访问你的服务时看到的结果取决于你服务器上的配置，而不是访问者本地的偏好。这也是排查”同一个铭文在你机器上看不见、在别处看得见”的关键线索——过滤发生在索引服务一侧。
工程上值得记住的配套细节还有两个。第一，用环境变量切换网络（比如指向测试网）做实验后，务必确认这个变量没有留在 shell 配置里——它优先级高过任何 yaml，会安静地把你以后每条命令都带去错误的网络。第二，配置文件字段与命令行永远不同名（下划线对连字符），写自动化脚本时统一从一个来源注入配置，别一半写在 yaml 一半拼在命令行里，否则未来维护者无法从文件里读出程序的真实行为。
再给三类高频怪象配上定位路径，方便对号入座。第一类，“参数明明加了却不生效”：九成是同名设置在更高层存在——命令行传了 —datadir，但 shell 里残留的 ORD_DATA_DIR 反而赢了；跑一次 ord settings 看 JSON 里的实际值立刻水落石出。第二类，“什么都没改却突然不对了”：检查默认数据目录是否被某次实验留下了 ord.yaml，自动加载规则让隐形文件比显式参数更早生效；用 —config 指到一个不存在的路径故意触发报错，也能反证当前是否真的在吃某个文件。第三类，“脚本在 CI 里好、在服务器上坏”：CI 是干净环境没有隐形层，服务器有历史残留——把配置全部收敛进版本管理的 yaml、命令行只留一次性的覆盖项，两边行为自然一致。这三条的共同解法仍然是同一句话：ord settings 的 JSON 输出是唯一的当场真相。
把优先链倒背如流之后，ord 的配置世界就没有秘密了：任何设置最多存在于四层中的一处或几处，生效者永远是”命令行、环境变量、ord.yaml、默认值”里最靠前的那个；ord settings 的输出就是最终答案。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。