作为一个小 Java ，请教下关于页面静态化的技术

拿无头浏览器搞 SSR 也不是不行

可以了解一下 next.js 对于你的需求有很好的文档解释和框架支持

@jmllx1963 这就去了解下

@learningman 表示懵逼

我主业不是 web ，之前了解过一点前后端分离，我也不太懂：
1. 后端只返回 json 这种方式好像是不利于 SEO ，比较好的方式是后端渲染成 html 返回？
2. 本质还是前后端分离，后端一样是返回 json ，但是不是直接返回到客户端，而是返回到一个服务器的中间层渲染成 html ，再返回到客户端。

我之前做的是提前生成静态页面到 nginx 目录下，访问的时候 nginx 直接返回静态页面，页面样式什么的都是前端写好，后端只用渲染数据就行了

接口缓存就可以了，让用户浏览器渲染是一样的，没必要整个页面全缓存，有的东西比如热榜还是可以变的

小项目，可以提前脚本生成静态页面保存下来，用户直接指向对应页面，比如:最近写的一个 nav 站点： https://github.com/putyy/nav

如果是已经成型的前后端项目，ssr 的处理方案会更好

html 模板前端调样式，后端通过模板生成 HTML 文件，放 nginx/静态文件服务器

这种现代 SSR 返回 HTML 不是你这边做的，都是前端侧出整套解决方案（ nextjs 等）做的，出这套方案的还是前端的活儿，不用你操心

就是分离了，前端也是写模板。前端样式都写好了，给你 <div>标题</div> ，你改成 <div>{{titile}}</div>，别把对方给你的 html 结构给写错了就完事了，哪来的难度。

如果网站是不太需要动态请求且内容固定的话就可以考虑生成静态页面，现在也有像 astro 这种技术让人用常用前端框架开发但是打包结果是一堆静态 html ，加载速度可以说是相当快了。
至于会不会让纯后端去写样式大可放心，除非你们公司的领导真觉得后端也要干这个。

前后端分离，Java 后端/Django 后端写好 Web API 相关服务接口，前端用 Html/Vue/Flutter ，调用接口获取数据，然后页面渲染。

Django 原生开发不使用 DRF 的话，就是需要写模板页面（ html 相关语句）的，感觉对比前后端分离来写，一个是开发代码更乱，第二个是为难开发人员不好协作，还有就是不利于多个前端（毕竟现在都恨不得跨平台），如果没有以上困扰，合一起写应也没啥

至于 html 难写的问题，如果不要求美观的话，基础的页面功能固定的话，可以考虑对应生成脚本/自己封装也行/找人帮忙封装一个也行，直接根据参数和相关选择生成对应代码

我记得十几年前国内互联网刚起步的时候 一些门户网站的内容页就是基本上纯后端生成的。。。。 可以看下 /t/843879

小项目用不上页面静态化技术，大项目会用单独的「前端的后端」跳过这种不靠谱的技术。

PHPer：编写这种模板 html 代码有难度？

静态生成页面对于后端而已确实属于上古技术了。

记得以前 jsp 的时代写过这类玩意，整体很简单，不过当时是做的 CMS 系统中有个按钮，“生成静态文件”，要监控变化就写一个定时任务轮询最新数据然后触发生成。
具体做法是 spring 自带类库就能实现还是额外引入其他插件我忘了，就是执行一下渲染逻辑然后存储为 html 到服务器上的某个 nginx 做了映射的路径里，然后更新相关链接引用的入口。


现在的做法其实算是交给前端做了， 前端目前有两项加速访问和 seo 友好的处理方法，SSR ，SSG 。
SSR 就是以前后端用的那种 服务端渲染， 和 jsp 、freemarker 一个意思，也需要在服务器端时刻运行他们的 node 服务器。
SSG 就是我上面提到的那个逻辑，执行的时候用 nodejs 发送 http 请求获取接口数据，然后根据数据生成渲染完成的静态页，然后就完事了，服务器端不需要有 node ，但需要你手动把本地生成的放到服务器上的对应目录。

目前前端也有自己比较成熟的框架， 差不多属于前端的 “spring” 了。
react 用 next.js
vue 有个类似的 nuxt.js

最开始全是后端写，后端渲染之后返回前端数据，jsp 之类的，后来有了专门写 html 的人，也是后端改成 jsp 写页面逻辑（那个时候公司后端 20 多个人，也就 2 个专门写页面的，每天求着人家给改页面。），再后来有一些后端模版框架，freemarker 之类的，后来就出现前后端分离，后端只提供接口，前端页面逻辑前端来搞，现在的话有一些静态渲染也是前端来做，他们在服务端渲染缓存，跟后端没啥关系，后端还是出接口返回数据就完了。

@zpf124 多些科普。 之前还了解到有方案是用 openresty 使用 lua 脚本在 nginx 上构建静态页，这种方案是不是也有点复古了？如果过时了，对于在 nginx 上做静态页缓存的技术，有继任者吗？

具体我也不懂，但是看别人简历，这种技术也一直在进步才对。
比如这位大佬
https://resume.lyn.one/
“Performance First 与 Robust First 的架构设计, 带领团队从 0 开始重写 https://tiktok.com, 它是基于 React ，TypeScript ，RxJS 的 SSR 应用, 在 LCP, TTI 等前端性能指标上与旧版本相比有最多 3 倍以上的提升。 在 Server 端性能指标上有 2 倍以上的提升, 缩减生产环境服务器核心数量大约 4000 个。TypeScript 类型覆盖 95% 以上, 极大减少了生产环境的 bug 数量与跨团队协作成本。”

上古的技术，java 服务用 jsp ，thymeleaf 之类的模板引擎直接返回 text/html ，nginx 反代，中间插一层 apache traffic server 之类的缓存/静态化服务，或者外面直接 cdn

@hanv2 在 nginx 上做缓存反倒在现在的模式下也可以正常使用，因为这种方式无需生成文件无需处理静态化后的请求连接的修改，不过我没实际涉猎过，不太懂也就不乱说了。

但一般而言，各类技术文章中都推荐 所有生成静态文件的缓存方式都最好只使用在不会经常发生改变的位置，如果你的缓存频率是小时、分钟这种级别的，那么前后端的缓存都有相应的技术可以满足，无须专门生成磁盘文件，你提到的用 nginx + lua 的方式也可以。

随便哪个模版引擎都支持单独调用输出成 html 就好了
比如 thymeleaf

之前给别人官网做过这方面的工作，主要就是调用模版引擎 thymeleaf 把数据拼接好写入到 html ，在项目启动和内容发生改变的时候重新生成页面，注意是连带着有关联的页面全都要重新生成

@GoRoad 这种属于比较传统的玩法了，至少六七年前就很成熟了，纯由后端来做的

1. 以前的后端直接返回 html 是因为以前页面基本都是 jps 或者模板框架做的，处理这些东西需要服务器额外的开销，所以搞了一套页面静态化 + 反向代理。现在基本都是前后端分离，后端只需要关心返回的 json 数据，即使需要 ssr ，也是使用 nextjs 一类的框架，由前端同学去处理。
2. 现在大部分公司的后端都不需要关心前端页面，但是有些公司依然在用 jsp 等老技术 ，如果你入职了这种公司，那么恭喜你，只用 jsp 在前人的屎上继续雕花了。

@hanv2 #25 是的 当时前端同学也没这方面的经验 干脆我们就纯后端来渲染了，前端写好样式模板，本身就是个官网，页面也不多