根据各种来源，在Rails 7中表单验证失败的方式是响应状态422不可处理的实体。然而，在我的例子中，这会导致Turbo发出另一个GET请求，这不太可能是期望的结果。
日志如下:
Started POST "/users/new" for 127.0.0.1 at 2022-06-16 17:27:48 +0200
...
TRANSACTION (0.3ms) ROLLBACK
...
Rendered html template (Duration: 0.0ms | Allocations: 4)
Completed 422 Unprocessable Entity in 133ms (Views: 1.2ms | ActiveRecord: 10.9ms | Allocations: 54437)
Started GET "/users/new" for 127.0.0.1 at 2022-06-16 17:27:48 +0200
...
因此，从Rails的角度来看，一切似乎都很正常，因为服务器响应所需的422状态码。在浏览器中检查响应时，我看到带有错误消息的表单。然而，由于某些原因，Turbo发出重定向到/users/new，而不是让浏览器显示包含错误的表单。
UPDATE:表单是使用simple_form_for生成的。
我怎样才能知道为什么Turbo重新加载页面?
最好的,Kalsan
当服务器响应一个表单帖子时，就会发生这种情况。返回完整站点，包括<html>等，可以解决问题。
远非Rails专家，但我见过一个Turbo表单提交，获得422:unprocessable_entity的响应，然后立即获得响应200的起始url。这是一个令人抓狂的无证文件。我在这里请求了官方文档帮助:
https://discuss.rubyonrails.org/t/do-we-need-official-rails-7-guides-for-integrating-with-turbo-to-counter-stackoverflow-cruft/83635
当Turbo无法在响应中找到完整的DOM时，就会发生这种情况。它不能比较你所拥有的和你所得到的，所以它只是践踏422和get。我在两种情况下见过这种情况:呈现部分响应而不是呈现完整响应，或者从没有布局的控制器呈现。
原因1:渲染部分而不是完全渲染
下面的代码将导致一个意外的GET 200，它会践踏您的422 unprocessable_entity:
# with app/views/_book.html.haml
render partial: 'book'
return
render partial: 'book', status: :unprocessable_entity
return
惊喜!你可能会认为涡轮增压的魔力能够清晰地识别出你的零件需要更换，但它不能。你会认为它会引发一个异常，但它没有。
另一方面也可以:
# app/views/book.html.haml
render 'book', status: :unprocessable_entity
现在你要求一个完整的反应和422棒。
描述render为完整响应的文档:
https://guides.rubyonrails.org/layouts_and_rendering.html creating-responses
原因2:控制器没有布局
有一个方法来选择你的布局和Rails可以选择没有布局或错误的布局，显然。
https://guides.rubyonrails.org/layouts_and_rendering.html finding-layouts
如果没有"more_different_book"布局:
# controllers/more_different_book_controller.rb
# no layout called for
def do_stuff
...
return render 'book', status: :unprocessable_entity
end
200 !
但是添加一个显式的(现有的)布局可以神奇地修复它:
# controllers/more_different_book_controller.rb
layout 'book'
def do_stuff
...
return render 'book', status: :unprocessable_entity
end
我可能误解了原因，但这就是我所观察到的以及我是如何克服它的。