先看看生成的报告效果
其实定制化做这种报告生成是很容易的，因为我在用poi-tl这个word模板引擎
Sayi/poi-tl: Generate awesome word(docx) with template (github.com)
做这个东西，自己基本上不太用得到，主要是公司项目会用；不过我做这个东西也主要是为了减轻自己的负担。上次攻防演练，去现场，本来中午就结束了，但是裁判要求整理报告格式，三个人硬干到了下午；攻防期间根本没心思好好整报告，结果就是打的成果越多，最后结束就越遭罪
然而单独针对某个模板现场开发报告生成器是不现实的，不说修Bug了，光是撸代码就能搞个半天，半天时间别的队伍都已经开始上分了
所以这次的产品设计目标是做一款能满足移动办公需要的通用报告生成器
两个需求：1、移动办公，2、通用
移动办公这个事好办，要么做成客户端每人电脑装一个，要么做成服务端扔公网上
这事在刚做的时候讨论了一下，大伙觉得可以公司内部推广，因为安全行业嘛，又是乙方，天天都要出不知道多少份漂亮的报告，让所有人畅享表单化办公，出报告既方便又整齐，还不容易漏填漏改，但是总不能手把手教每个人怎么安装java17、怎么排除8080端口占用等问题，所以还不如把并发性能做强一点，塞服务器上
所以现在这个东西就要做成：既拥有一定的并发性能，又方便携带，随时原地部署
既然要并发性能、又要原地部署，那数据库方面就不能用sqlite，sqlite并发性能稍微弱一点；我在google冲浪的时候发现一个java数据库跑分网站，应该是objectdb的广告站，不过我不用objectdb（好像用的人不多，怕踩坑），所以我仔细看了一下
JPA Database Performance Comparison - Benchmark Test: all-all-all (jpab.org)
嵌入式数据库里面，H2和HSQLDB的性能都不错，然而HSQLDB在百度上找不到什么资料，所以我考虑用H2数据库
然而据说H2数据库在意外关闭的时候会爆炸，不知道现在最新版有没有这个问题
Why use SQLite over H2 for java application - Stack Overflow
我自己试了一下，杀进程几次好像也没事，应该是没负载的情况下意外退出是没事的
反正用一下试试，一般报告这种东西都会直接导出word版存档的，数据安全性问题不大
接下来就是通用的问题，这里的通用指的是不需要针对每个模板的报告开发一个专用服务，其实后端这里好解决，弄个接口标准就完事了，逻辑也好弄
但是前端咋办？要具备生成任意模板报告的能力，那就要求前端具备接受任意输入的能力
综合考虑下来，感觉用动态表单的思路去做是最合适的，因为用户只需要预先设置好表单内容并保存，后续只要直接填写内容就能喂给报告生成器了
那要做动态表单的话，前端技术怎么选型呢？
首先排除传统的html技术，因为这种页面主要依赖后端渲染，如果不使用后端渲染，直接使用js去拼接感觉工作量太大；而如果使用后端渲染的话，每添加一个填写框就要刷新一下页面，这种使用体验还是比较坏的
那就用vue，我已经做好了，大伙可以先看效果
图中的“7”是一个列表，大伙都知道很多时候列表里面会塞大东西，比如我们的渗透报告，列表里面包含每个漏洞的详细信息、漏洞危害、漏洞名称等，所以我通过递归套娃的方式把这个东西做出来
那这个“能套娃的动态表单”是具体怎么实现的呢？
我估计直接干代码出来大伙也不想看，我画个图吧，也不难做
大伙可能注意到有这个组件
这个是一段用户自定义函数，可以叫它UDF，这玩意会在导出报告的时候由浏览器执行，函数的参数就是整个js的带数据的报告模板对象，return值会作为这个字段的值传递到服务端，在渗透报告场景下，可用来统计漏洞列表的漏洞数量、生成当前时间等
其他就没什么了，但是我感觉我做的这个挺实用，接下来可以考虑做协同编辑，某个用户编辑一个表单元素时（元素获得焦点），就给那个元素上锁（前端disable），失焦或者缺失3-5次心跳包时自动解锁，然后元素的值变化事件通过websocket与服务端同步，直接推送给所有客户端
不过协同功能估计需要很猛的服务器CPU和内存，毕竟用户数多的时候这流量还是不小的
协同功能还要考虑实时保存问题，对于当前的数据库存储模式来说（数据转化成json字符串存储）是个问题，我感觉只能说服务端把这个json结构实例化暂驻内存，值变化事件到达服务端的时候上锁去改内存对象，每隔几秒就把对象持久化到数据库里，但是如果图片特别多（base64格式），这个json结构又吃内存，这大概就要写个图床功能，图片传图床，然后存个链接…
协同功能除了推送/保存/锁等主要的技术实现问题，还有很多细节问题需要考虑，这就只能到时候再说了
先看看这玩意大伙喜不喜欢，再考虑是不是接着做协同功能吧