这确实符合规范。以下是
UIInput#validate()javadoc（重点是我的）的相关摘录：
使用检索提交的值
getSubmittedValue()。如果返回null，并且
ALWAYS_PERFORM_VALIDATION_WHEN_REQUIRED_IS_TRUEcontext-param的值为true（忽略大小写），请检查“ required”属性的值。如果“ required”的值为true，则继续执行以下操作。如果“ required”的值为false或未设置required属性，请退出而不进行进一步处理。如果未设置context-param或将其设置为false（忽略大小写），请退出而不进行进一步处理。（这表明没有为此组件提交任何值。）
空输入将发送空字符串，而不是null。完全不输入将发送null，而不是空字符串。
因此，您可以通过添加以下上下文参数来禁用观察到的行为：
<context-param> <param-name>javax.faces.ALWAYS_PERFORM_VALIDATION_WHEN_REQUIRED_IS_TRUE</param-name> <param-value>true</param-value></context-param>
请注意，此上下文参数是自JSF 2.3起新增的，并已反向移植到
Mojarra 2.2.16、2.1.29-10和1.2_15-06中。在旧版本中不支持。另请参见JSFSPEC-1433和有关此问题的专家组讨论。
这是否有害取决于业务逻辑。如果设计得当的模型（业务逻辑和/或数据模型）不符合null预期的情况，则会在其他地方导致空指针异常或SQL约束违反（NOT NULL），通常会导致HTTP 500错误响应。但是，如果模型实际上将其null视为预期情况，则很可能是模型中的错误。旨在仅呈现模型的视图（JSF页面）然后可能对此没有多大作用。
如果确实不能更改业务逻辑或数据模型以将其视为null例外情况（即，永远不要假设/接受给定的值作为null），而您碰巧使用了JPA，那么最好的选择是@NotNull在属性上添加一个。尽管JSF将绕过其验证，但JPA仍将对其进行验证，从而仍然导致异常和HTTP 500错误。在这种情况下，我只想知道为什么DB列首先没有NOT NULL约束。或者，进行类级别验证。
应该注意的是，MyFaces会在下面记录如下警告：
2016年3月16日，上午8:55:52 org.apache.myfaces.shared.renderkit.html.HtmlRendererUtils enpredecryptInputInput
警告：如果呈现了输入，呈递了其形式且未提交，则输入应始终有一个提交值最初被禁用或只读。您无法通过javascript禁用输入元素后提交表单。在提交表单之前，请考虑将只读设置为true或将禁用的值重置为false。
组件：{Component-Path：[类：javax.faces.component.UIViewRoot，ViewId：/test.xhtml] [类：javax.faces.component.html.HtmlBody，Id：j_id_5] [类：javax.faces.component .html.HtmlForm，Id：j_id_6] [类：javax.faces.component.html.HtmlInputText，Id：j_id_7]位置：/test.xhtml，第22行和第33列}
