combobox 的 state="readonly" 必须在初始化时设置，事后用 configure() 修改在部分 tk 版本（尤其 windows）易失效；它允许展开选择并触发事件，而 "disabled" 则完全禁用交互。
Combobox 的 state="readonly" 必须在初始化时设置
不是“无法限制”，而是很多人误以为可以先创建再改状态。ttk.Combobox 的 state 属性一旦控件被渲染（即调用 pack()/grid() 后），再用 configure(state="readonly") 修改，**部分 Tk 版本会失效或行为不一致**——尤其在 Windows 上常见光标仍可聚焦、键盘仍能输入的假象。
真正可靠的写法是：把 state="readonly" 作为构造参数传入，而不是事后配置。
- ✅ 正确：
combo = ttk.Combobox(root, values=["A","B"], state="readonly") - ❌ 危险：
combo = ttk.Combobox(root, values=["A","B"]); combo.configure(state="readonly")
state="readonly" 和 state="disabled" 的关键区别
选错状态会导致交互完全中断，而非仅禁输入。两者表面都“不能输”，但底层逻辑完全不同：
-
state="readonly"：文本框只读，但下拉箭头可用，用户点击后能展开列表并用方向键/鼠标选择；事件如>正常触发 -
state="disabled"：整个控件灰化、不可聚焦、不响应任何点击或键盘，>也不会触发
如果你需要“只读但可选”，必须用 "readonly"；若用 "disabled"，用户连点下拉箭头都不行。
为什么加了 state="readonly" 还能输？常见漏掉的点
即使写了 state="readonly"，仍可能被绕过，原因通常是以下之一：
- 没清空
textvariable绑定的StringVar初始值 —— 如果该变量已有内容，且未设默认选项（如没调用current(0)），Tk 可能回退到“可编辑”模式渲染 - 手动调用了
combo.set("xxx")之后又没重置状态，某些旧版 ttk 在 set 后会悄悄松开只读锁 - 绑定了
validate或validatecommand，而验证函数返回了False，导致 Tk 内部状态紊乱（这种组合极少必要，反而容易破坏readonly行为）
动态切换只读/可编辑状态的可靠做法
真有运行时切换需求（比如根据复选框勾选状态控制 Combobox 是否可编辑），不能依赖反复 configure(state=...)。稳妥方案是：
- 用
state="normal"初始化，但配合bind("<focusin>", lambda e: e.widget.focus_set() or e.widget.selection_clear())</focusin>抑制聚焦输入（不推荐，体验差） - 更干净的做法：销毁旧 Combobox，重新创建一个带新
state参数的新实例，并复用原values和textvariable - 或者直接换用
ttk.OptionMenu—— 它天生只读，无输入框，适合纯单选场景
最易被忽略的是：Tkinter 的 readonly 不是“防篡改”，它只是 UI 层限制；程序内仍可通过 set() 或修改绑定的 StringVar 改变值。需要数据一致性，得靠逻辑层守门，不能只信 UI 状态。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
