MFC编辑框写入文本为何使用SetSel、Clear而非直接覆写

你给出的第一种直接调用SetWindowTextW覆写文本的写法，在使用标准Win32/MFC原生Edit控件的场景下是完全正确、符合官方API设计预期的，额外加全选、清空操作的写法绝大多数时候都是无意义的冗余代码，具体说明如下：

两种写法的实际行为对比 #

你写的简洁实现逻辑：

m_edit1.SetWindowTextW(_T("this is edit"));
// 直接全量替换控件文本，系统内部自动完成旧文本销毁、新文本写入、控件重绘
m_edit1.SetWindowTextW(_T("second"));

你看到的冗余实现逻辑：

m_edit1.SetWindowTextW(_T("this is edit"));
// 全选所有文本
m_edit1.SetSel(0, -1, TRUE);
// 删除选中的文本
m_edit1.Clear();
// 再写入新文本
m_edit1.SetWindowTextW(_T("second"));

对于标准Edit控件，这两段代码最终的显示结果完全一致，后者反而会多发送2条编辑框消息、多触发至少1次额外的控件重绘，性能上更差。

这种冗余写法的来源 #

这种写法不是官方推荐的标准写法，之所以会在很多旧代码里出现，基本是以下几个原因：

• 历史遗留的临时修复方案被误传为标准实践：早年很多第三方派生的自定义Edit控件（比如带输入掩码、语法高亮、特殊输入校验的魔改控件）重写SetWindowText方法时存在实现bug，直接调用无法正确触发内部状态刷新，必须手动全选清空再写入新内容才能正常显示。很多开发者把这个针对特定bug控件的解决方案，不加区分套用到了标准原生控件上，慢慢就传开了。
• 错误的"模拟用户操作"思路：有开发者认为手动全选删除再输入，更符合真实用户编辑文本的操作逻辑，能让撤销栈行为更贴近手动操作——但实际上这个行为非常不稳定，不同Windows版本、不同控件样式（比如是否是多行控件、是否开启自动撤销）下，撤销栈的记录逻辑差异很大，靠这种方式控制撤销行为完全不可靠。
• 纯无意义的拷贝遗留：很多开发者写代码时直接照搬旧项目的片段，根本不会验证每一行代码的实际作用，反正加了这两行也不会抛错，就一直保留在代码里了。

实际开发建议 #

只要你使用的是系统原生的标准Edit控件，没有使用有bug的第三方自定义派生类，直接调用SetWindowTextW修改文本就是最优写法。如果是在控件持有输入焦点的场景下修改文本，只需要在赋值完成后按需设置光标位置/选中状态即可，完全不需要提前执行全选、清空操作。

内容的提问来源于stack exchange，提问作者Zrn-dev