Express中为何约定出错时重渲染页面、成功时才执行重定向？

这个「错误重渲染页面、成功执行重定向」的约定，是web开发领域*POST/Redirect/GET（PRG）*最佳实践的延伸，设计初衷是平衡业务安全性和用户体验，核心逻辑如下：

为什么成功场景必须重定向 #

表单提交大多用POST请求，这类请求是有副作用的（比如新增数据、修改状态、发起支付等）。如果提交成功后直接渲染页面，用户点击浏览器刷新按钮，会触发重复的POST请求，很容易导致数据重复写入、重复扣费等严重业务问题。
重定向到GET页面后，用户当前浏览器的地址栏就变成了GET请求的地址，无论怎么刷新，都只会触发无副作用的GET请求，不会重复提交表单，从根源上规避了这类问题。

为什么错误场景默认推荐重渲染 #

错误场景下用户的POST请求并没有执行实际的写入操作，就算用户刷新重复提交，也不会产生业务风险，所以没有必须重定向的硬性要求。此时选择直接重渲染，主要是为了更低成本实现更好的用户体验：

• 直接重渲染可以直接把用户提交的原始表单参数回传给视图，用户之前填的所有内容都会保留，只需要修改错误项即可，不需要额外开发逻辑
• 如果错误场景也走重定向，你必须把所有表单参数存入session，重定向后再取出回填，否则用户填了半天的内容会全部清空，体验极差；除此之外还要处理多标签页提交的session冲突、过期清理等额外问题，反而提升了维护成本

你遇到的繁琐问题的优化方案 #

你觉得每次手动传flash对象麻烦，完全不需要推翻现有约定，只需要微调你的中间件逻辑即可：你现在写的全局中间件已经把flash内容挂载到了res.locals，不管是重定向后的render，还是错误场景直接render，视图默认都能读取到res.locals.flash的内容，你完全可以删掉错误处理时手动传递flash的代码，不需要每次都写。

能不能全场景统一用重定向？ #

当然可以，这个约定不是强制规则，只是权衡成本后的通用最优解。如果你的业务场景都是短表单，或者你愿意投入成本处理表单回填、session冲突等问题，全场景统一走重定向完全没问题，代码逻辑确实会更统一。

内容的提问来源于stack exchange，提问作者bugsyb