selenium通过execute_script设置日期时出现月日颠倒，根本原因在于目标输入框期望的日期格式（如mm/dd/yyyy）与脚本传入的格式（如yyyy-mm-dd）不匹配，浏览器按自身解析规则误判字段含义。
selenium通过execute_script设置日期时出现月日颠倒，根本原因在于目标输入框期望的日期格式（如mm/dd/yyyy）与脚本传入的格式（如yyyy-mm-dd）不匹配，浏览器按自身解析规则误判字段含义。
在Web自动化测试中，使用 driver.execute_script() 直接向 或 等元素注入日期字符串是一种常见做法。但需明确：execute_script 仅执行字符串赋值，不进行任何日期解析、校验或格式转换。浏览器后续如何解释该字符串，完全取决于输入框的类型、所在地区的默认解析逻辑，以及前端框架（如React、Vue）是否绑定自定义日期处理逻辑。
例如，当执行以下代码：
start_time = self.driver.find_element(By.XPATH, '//*[@id="start-time"]')
self.driver.execute_script('arguments[0].value = "2024-02-20 16:00"', start_time)看似符合ISO 8601标准（yyyy-mm-dd HH:MM），但若目标输入框是纯文本型且前端JavaScript预期 mm/dd/yyyy 格式（常见于美式本地化应用），浏览器可能将 "2024-02-20" 错误地拆解为：
- 2024 → 年（无歧义）
- 02 → 被当作月份（正确）
- 20 → 被当作日期？但 20 > 12，无法作为月份 → 此时部分浏览器/脚本可能触发回退逻辑，尝试交换解析顺序，导致 02/20 被误读为 20/02（即20号作为月、2号作为日），最终呈现为 20/02/2024 或报错。
✅ 正确做法是严格匹配目标输入框声明的格式要求：
- 若HTML中 的 type="date" 或 type="datetime-local"，应使用 yyyy-MM-dd 或 yyyy-MM-ddTHH:mm（注意T分隔符）；
- 若为普通 type="text" 且页面JS明确要求 mm/dd/yyyy HH:MM（如美国地区表单），则必须传入对应格式：
# ✅ 正确：匹配前端预期的 mm/dd/yyyy HH:MM 格式
self.driver.execute_script('arguments[0].value = "02/20/2024 16:00"', start_time)
# ✅ 更健壮：动态生成（避免硬编码）
from datetime import datetime
dt = datetime(2024, 2, 20, 16, 0)
formatted = dt.strftime("%m/%d/%Y %H:%M") # → "02/20/2024 16:00"
self.driver.execute_script('arguments[0].value = arguments[1]', start_time, formatted)⚠️ 关键注意事项：
- 不要依赖execute_script做日期智能转换：它不是Date对象操作，只是字符串写入；
- 优先检查HTML源码与前端文档：确认输入框type属性、pattern正则、placeholder提示及关联的JS验证逻辑；
- 考虑使用send_keys()替代（谨慎）：对支持原生日期控件的浏览器，element.send_keys("2024-02-20") 可能更可靠，但需确保焦点和事件触发完整；
- 自动化前手动验证格式：在浏览器控制台中执行 document.querySelector('#start-time').value = "02/20/2024 16:00"，观察实际渲染效果，再同步到脚本。
总结：日期格式错乱本质是“人机约定不一致”问题。解决路径始终是——以被测应用的格式规范为准，而非测试者的直觉或通用标准。精准匹配输入格式，辅以动态生成与前置验证，即可彻底规避月日颠倒陷阱。
