静态化一方面是为了提升访问性能，另一方面要保证数据实时性。
**静态化前提是模板 + 数据的渲染引擎，例如基于java的velocity以及Thymeleaf，基于Ruby的erb, haml, slim，基于nodejs 的 jade、ejs、swig，前端的 mustache、Juicer、Hogan.js ，php的twig ，Python 的Jinja2等等等……
**
一、初始全站静态化
站点（site）启动时期没有任何静态化文件（HTML），首次启动站点静态化时，采用全站静态化的方式对已有数据静态，全站静态分为以下两种形式：
1.所有数据一次性静态化
在服务器（server）压力允许时候，即数据量在可控范围内，对全站进行一次性数据静态化，此处暂时不考虑数据变化，例如数据临时撤销\删除\修改（CRUD）等操作
2.分批次将所有数据静态化
若数据库数据庞大且不可控，可能会严重影响静态化性能切延长操作时间，此情况考虑分批次静态，优先静态化部分常访数据（此处定义最新数据，亦可根据访问量定），通过系统参数的配置的形式，静态化到哪一部分时可停止，对于未曾静态化的数据，采用正常请求形式访问，切访问首次将其通过局部静态化的方式静态化，以备之后的访问。此外，若要将未曾静态化的数据再次统一静态化，可在手动启动静态化程序。
二、局部静态化
局部静态化分为三种形式：
1.可变碎片静态化（debris）
碎片静态化一般作为多数页面常用的且数据更新相对频繁的页面中的局部区块（主页推荐，栏目相关数据推荐），在第一次静态化之后，重点是如何触发数据更新之后的复静态化，这等依赖于数据实体（model）本身的设计与后台其他服务的监听机制，此处提供一个机制就是数据实体本身提供一字段叫做是否，在实例化到数据化之后判断是否次字段为触发的条件，成立时启动更新静态化碎片操作。
2.不可变碎片静态化
一般来说数据极少更新的部分碎片静态化（合作单位，主页相关站但链接等），第一次静态化之后访问页面只要存在均可直接嵌入使用，这部分更新时直接手动更新即可
3.页面静态化（page）
页面相对与整个站点来说是主要的部分，而且页面可以说基本上不会是纯静态化HTML文件，页面基本上是碎片（可变碎片与不可变碎片）、单条数据详情、列表页为主体，其他细节基本是依赖于这几部分中的数据进行变化，对于页面中使用的碎片方式，此处建议考虑ngnix分布式服务器的形式使用，ngnix中的提供语法惊醒HTML文件的嵌入，且现在使用ngnix作为静态化代理服务器是一般常见做法。
当然页面中有些数据是请求时候就必须更新的，所以此类数据基本不适后台处理，一般在加载页面之后通过脚本的方式异步请求获取（数据点击量）。
三、后台静态化文件存储形式（folder directory）
后台静态化的HTML存储形式可结合页面类型，数据类型，数据唯一标识进行命名存储，静态代理访问HTML页面时，通过一定的规则拼凑转换找到对应文件返回即可。
四、后台定时启动静态化程序（timer）
除了手动启动静态化程序以及初始化全站静态化之外的方式，需要提供自动静态化的API接口，在管理员规定的时间中进行静态化操作，通过设定定时器启动程序，前者对应的效果。
五、如何实时静态化数据及HMTL文件（RealTime）
数据有模型数据提交之后，如若还是以静态HTML 的形式访问页面，就得实时更新已存在的HTML文件，而更新的是设计到当前所提交的模型数据的页面，所以只需更新此部分即可。一般是动态碎片，其中以推荐为主，此处参考二中的1点。