命令行补报表参数总输错：用 readline 做路径和字段名补全及历史留痕 #
文档明确的机制 #
Python 标准库 readline 的定位很直接：它提供补全，以及历史文件读写能力。文档说明，这些设置不仅影响 Python 交互式解释器，也会影响内置 input() 给出的提示。因此，在团队内部的 Unix 终端 Python 运维或报表小工具里，可以把它用于减少目录、报表类型、字段名等参数的手工输入错误。
它不是跨平台图形界面组件。文档给出的可用性边界是：不支持 Android、iOS、WASI；该模块在 Unix 上可用，而且属于可选模块。如果 CPython 中缺少它，需要查看 Python 提供方的说明。底层也不一定总是 GNU readline：可能由 editline/libedit 实现；在 macOS 上，模块会在运行时检测后端。文档还提醒，不同库可能使用不同的历史文件格式，切换底层库后，已有历史文件可能无法继续使用。
自定义补全的核心接口是 readline.set_completer(function)。文档规定，补全函数按 function(text, state) 调用，state 从 0、1、2…… 递增，直到函数返回非字符串值；每次应返回一个以 text 开头的候选。报表工具可以把已知字段名、报表类型或候选目录作为列表，再按当前 text 过滤。补全通常通过 Tab 触发，文档示例使用 readline.parse_and_bind("tab: complete") 绑定该行为。
路径和字段名通常需要不同的分隔规则。set_completer_delims(string) 用于设置补全时的分词符，这些字符决定“当前要补全的词”从哪里开始；对应地，get_begidx() 和 get_endidx() 可取得补全范围。文档也明确提示，libedit 与 libreadline 在这些索引上可能表现不同，所以终端行为需要在实际后端上验证。
历史方面，read_history_file([filename]) 可读取历史文件，默认文件名为 ~/.history；write_history_file([filename]) 会保存历史列表并覆盖已有文件；append_history_file(nelements[, filename]) 只追加最后若干条，但要求文件已经存在，并且只有编译时所用库版本支持时才存在。set_history_length(length) 控制写入历史文件时希望保存的行数；文档说明负值表示不限制。get_current_history_length() 返回当前历史项数量，它不同于“将写入文件的最大行数”。若想自动加入历史，可使用 add_history(line)；set_auto_history(enabled) 可控制通过 readline 读取输入时是否自动调用加入历史，且该设置默认开启、不会跨会话保留。
初始化配置可通过 parse_and_bind(string) 执行一行初始化指令，也可用 read_init_file([filename]) 执行初始化文件。GNU readline 通常使用用户主目录下的 .inputrc；macOS 上若使用 editline/libedit 模拟，文档给出的初始化文件是 .editrc。程序还可通过 readline.backend 查看底层库名称，该属性在 Python 3.13 中加入。
还有一个 REPL 边界必须写清：Python 3.13 引入的新 REPL 不支持 readline；文档说明仍可通过设置 PYTHON_BASIC_REPL 环境变量使用 readline。
团队自行约定的接手建议 #
以下是团队接手时可自行约定的做法，不是 readline 文档承诺的产品能力。
第一，把候选数据来源固定为受控列表。例如报表类型使用明确枚举，字段名使用脚本内维护或由报表元数据生成的列表；路径候选可来自团队约定的报表根目录。不要把 readline 说成权限校验或文件存在性校验：它只负责交互补全和历史，最终仍应由程序检查路径、字段和报表类型是否有效。
第二，在脚本启动时读取团队专用历史文件，退出时写回，并设置明确长度，例如 1000 行。文档示例也使用 1000 行展示长度限制。为避免多个终端会话相互覆盖，可参考文档第二个示例：启动时记录当前历史长度，退出时只追加新增条目；使用追加方式前要确认 append_history_file 存在，并保证历史文件已创建。
第三，把路径和普通字段分开补全。选择报表目录时，可把分隔符设置得适合路径输入；选择字段名时，再使用适合逗号、空格或其他参数分隔的规则。每次提示前都应显式设置对应 delims，避免上一个提示留下的分词规则影响下一个提示。
第四，把平台检查写进启动逻辑。目标环境限定为团队内部 Unix 终端；在 macOS 上记录或显示 readline.backend，并实际测试 Tab、路径分隔和历史读取。若导入失败或运行在 Android、iOS、WASI、Web 页面、GUI 程序中，应降级为普通 input()，不要声称补全仍可用。
第五，Python 3.13 及后续环境若要在交互式 REPL 中验证 readline，应按文档使用 PYTHON_BASIC_REPL。脚本内调用 input() 的验收则应在目标 Python、目标后端和真实终端中完成，避免只用另一个 REPL 的表现推断。
边界与总结 #
readline 适合解决的是终端输入层问题：在 Unix 终端里，为 Python 交互解释器或 input() 提供自定义候选补全、按键绑定和历史读写。它能帮助操作员少敲长路径、少记错字段名，但不能替代参数校验、访问控制、审计、文件锁或 Web/GUI 交互。
还应保留三个兼容边界：其一，模块可选，且不支持 Android、iOS、WASI；其二，底层可能是 GNU readline 或 editline/libedit，配置文件和历史格式可能不同；其三，Python 3.13 新 REPL 默认不走 readline，需要 PYTHON_BASIC_REPL。
因此，推荐的落地区间很小：只在团队内部 Unix 终端的 Python 报表小工具中，用受控候选列表配合 set_completer、set_completer_delims、parse_and_bind 和历史文件接口；上线前在实际后端验证补全范围、历史保存与多会话追加。不要把它扩展成 Web 自动补全、跨平台 GUI 能力，也不要假设不同 readline 后端的历史文件一定兼容。
相关工具 #
AI 工作流 ROI 诊断器 · 查看工具的输入要求、输出说明与适用范围。