手机日期输入验收，不能只检查点一下是否出现日历。访客能不能选到目标日期、清除误选、理解时间含义，以及提交后日期是否仍正确，都影响这项字段能否实际使用。
原生日期控件在不同浏览器和操作系统中的外观、操作方式可能不同。验收应围绕同一个业务日期完成任务，而不是要求所有设备显示完全相同的日历。先定义日期含义，再核对输入、修正和保存。
日期先表达业务关系，再决定控件
项目表单里的“启动日期”可能指开始沟通、开始设计或进入开发；“完成日期”也可能指希望上线、内部审核结束或项目交付。标签过于简短，用户即使选对一天，双方仍可能理解不同。
可以采用更具体的标签，例如“希望开始沟通的日期”或“期望上线日期”，并说明它是客户预期，还是已经确认的安排。初次需求里的愿望，不应自动变成企业承诺的交付日期。
如果客户提供的是大致月份，精确到某一天可能产生虚假的确定性。可以按实际需求提供月份或未定说明，而不是要求他随便选月初。字段精度应与沟通任务匹配，只有后续流程确实需要具体日期时，才要求完整年月日。
如果同时收集启动与完成时间，需要明确关系。通常完成不应早于启动，但是否允许同一天，应由业务决定。若两个字段代表不同阶段，也要说明，不能只凭名字设置一条不适用的限制。
未确定日期需要有独立表达。可以允许留空，或提供“时间暂未确定”的选项。不要用今天自动代替空值，也不要把用户没有操作过的默认日期保存成他主动选择的计划。
假设一位访客只想先讨论改版范围，尚无上线日期，表单应让他如实表示未定。接收团队之后结合内容准备和实施条件继续讨论，不必在第一次咨询时强迫客户猜一个日期。
在真实手机上完成选择与修正
手机上的原生日期控件可能采用滚轮、分段输入或日历，形式由系统决定。验收时应实际操作目标设备，确认用户能从当前日期到达所需日期，并能知道自己选择的年、月、日。
尤其检查远期日期。控件能打开，不代表选择几个月后的日期容易。若业务常收集较远时间，应试着完成这项任务，观察需要多少切换，以及年份变化是否清楚。
如果浏览器允许键盘或分段输入，应核对正常输入、删除和重新填写。如果某设备主要提供系统选择器，也应确认存在可用的完成路径，不宜为了让所有手机“能手输”而仓促换成更容易出错的自由文本框。
清除是容易遗漏的动作。用户选错后，应能够修改；允许日期未定时，也需要能恢复空状态。若日期控件无法自然清除，可以提供合适的重置或未定操作，但要避免误清其他字段。
键盘、选择器和页面滚动之间的关系也需要检查。提交按钮不能被遮挡，日期说明不能因控件打开而消失，关闭后应能继续填写。桌面缩小窗口无法完整模拟系统键盘与原生选择器。相关操作可参阅《手机端复杂表单怎么设计？键盘、校验和分步提交》。
触控区域和标签要便于操作。不要只让一个细小日历图标可以点击，也不要仅靠占位文字解释日期用途。用户修改已有值时，仍应看得到字段标签与规则。
空值、过期与非法日期分别处理
空日期是否允许，取决于业务规则。必填时提示补充；允许未定时正常提交。不能把“未选择”写成“格式错误”，也不能将它自动转换成一个看似有效的日期。
过去日期不一定都非法。例如收集现有项目的开始时间，可以允许过去；收集未来预约，则可能限制早于当前日的输入。规则需要对应任务，不要给所有日期字段统一设置只允许未来。
日历不存在的日期属于另一类问题。自由输入方案要检查年、月、日组合是否有效；原生控件也需要在服务端核对最终提交值。页面显示合理，不代表所有请求都来自正常操作。
规则触发时也要保留另一个日期。修改启动时间导致原完成时间不再符合关系，应提示用户重新确认，不能静默删掉结束值后继续提交。用户要能看到冲突来自哪两个条件，才能选择正确的修正方向。
两个日期的先后关系，应在第二项输入或提交时清楚提示。例如“期望上线日期不能早于希望启动日期”，并让用户能够修改其中一项。错误内容应描述关系，不要只写“日期无效”。
若选了较近日期，系统是否直接拒绝，也需要业务依据。初次咨询可以允许客户提出期望，再说明需要讨论；有固定预约能力时则按实际安排限制。不能让内容编辑随意规定一个最短工期并写进校验。
展示格式与保存的日期值分开
原生日期输入的显示格式可能随浏览器地区变化，标准值采用年、月、日的明确顺序。用户看到的本地格式与系统保存形式可以不同，只要代表同一天，并且摘要不产生歧义。
自由文本中的纯数字日期更需要谨慎。例如月、日顺序在不同地区可能不同。可以提供清楚的格式说明，或在核对页使用不容易误读的完整表达，而不是只给一个容易被交换理解的短数字串。
只有日期而没有时间的字段，不应随意转成时区时间再格式化。开发若采用不合适的转换，可能在某些地区显示成前一天或后一天。业务日期通常需要保持客户选择的年月日，具体实现由开发核对。
日期和提交时间要分开。客户选择期望上线日，不等于需求提交日；保存记录自动产生的时间，也不能回填到客户日期字段中。后台标签要让接收人员明确区分这些信息。
语言切换时可以调整展示文字，但不能改变日期本体。摘要、通知和后台都需要采用清楚的含义与格式。最终看起来美观，还要确认接收人员据此理解的是同一天和同一业务阶段。
用边界样本核对输入到记录
准备样本时至少包括正常未来日期、未定、过去日期、年末跨年、月末，以及开始与结束的不同关系。若支持自由输入，再加入不存在的日期与不完整输入，检查提示与修正路径。
每条样本写明预期。例如允许未定应能提交，违反先后关系应获得提示，合法日期应保存为同一天。测试人员若没有预期，只能记录控件外观，很难判断规则是否正确。
选择几种实际目标设备与浏览器完成操作。若客户主要从手机访问，就把手机作为验收入口。不要仅用开发电脑证明原生日期输入已工作，更不要拿某个设备的截图推断所有系统操作都相同。相关操作可参阅《网站开发测试清单：功能、设备、浏览器、性能与安全》。
设备核对还可以跨地区显示条件进行受控验证：保留相同日期值，观察不同地区格式如何呈现。测试记录应写清原始年月日，而不是只附一张数字次序不明的截图。这样发现显示差异时，可以判断只是格式不同还是实际日期已经变化。
选定后查看摘要，再提交到后台，并检查通知。比较业务标签、年月日和未定状态。若输入正确而摘要错一天，说明问题在展示或转换；若后台本身不同，则要继续核对提交与存储。
还应返回修改日期、清空已选值、恢复草稿及切换界面语言。成功标志是合法日期可输入，错误可修正，空值按规则处理，跨设备与实际保存没有含义变化。仅日历弹出，无法满足这些要求。
把日期口径、边界规则和已验收设备保留在交接记录中。以后更换组件或调整时间条件时，复用同一批样本，可以避免新界面只修了外观却破坏原有规则。
常见问题
手机日期控件必须长得和电脑一样吗？
不必。原生控件会受浏览器和系统影响。应核对是否能完成选择、修正和提交，以及结果一致，而不是要求每台设备拥有相同日历外观。
所有手机都需要允许手动输入日期吗？
应保证实际可用的输入路径。如果平台支持手输或分段输入，需要验收；如果主要使用系统选择器，要确保它可完成任务，不能只为了统一外观换成无约束文本框。
日期未定时可以自动填今天吗？
不宜。未定、未操作与主动选择今天含义不同。允许未定就保留该状态，必填则提醒选择，不要用默认值制造不存在的计划。
日期在另一设备显示错一天，应先查什么？
先比较原始选择、提交值、存储和摘要，再核对日期是否经过时间及时区转换。只有日期的业务字段，应保留其年月日，不能凭显示结果猜测客户选错。
什么才算手机日期输入验收通过？
约定设备能完成输入和修正，边界规则准确，摘要、后台和通知代表同一天及同一业务含义。空值与未定也按规则处理，控件能打开只是其中一步。
链接复制成功
