一、概况
在微信小程序端显示电子合同，并填写完后签名，生成对应的pdf。
二、所涉及的知识点
- 开源组件：xdocreport的使用
- 文件的 I/O 流
- spring框架中，使用
MultipartFile来接受文件流 - Files类的使用
- 渲染模板通用规则的设计
三、难点
word文档模板的创建
最恶心最耗时的步骤，变量名严格的一对一对应，而且还要自己注意格式的设置，技术含量不高，但非常的繁琐。如下图：
需要在待填充的区域 用上**占位符 **首，以及命名相应的变量，要注意的是直接打开word的那个变量不是有效的，只是用来显示，真正有效的变量要 按 Ctrl + F9 显示, 如下图:
由于用到的占位符比较多，怎样设定命名规则也是要好好想想的。而且还要考虑如何在数据库进行数据的读写，我使用的命名规则如下：
PS:图片通过设置书签名来命名。 选择题用的是 Int 类型进行储存，
优点：是简洁（暂时自己能想到的最简方案），与前端交互方便（通用规则简单），
缺点：只能是个位数的选择题数量
IO流在实际项目里的运用
- 一定要记得关闭流。我采用的是
try(){}catch{}的语法，可以不用手动使用finally来关闭流,也让整体代码看上去更加的简洁。
2. 流的操作是不可逆的。InputStream 进行了一次读写之后就不能重复读了，而是要创建新的Inputstream，好像还可以在stream上打记录点，但试过几次并不能得到想要的效果，有空可以深入研究~
业务逻辑上的判断
租赁合同到底是承租方还是租赁方签名，要分清楚且要分别在数据库添加判断是否签名的字段 if_sign ， 还要判断对方是否签名，如果已签名，则在获取电子合同时也要把签名渲染上。如： 承租方已签名，在租赁方也签名后生成新的pdf覆盖原有的pdf，此时渲染图片的时候要渲染上承租方的签名图片。因此每次渲染签名图片时都要判断对方是否已签名（容易忘记）。
回滚操作
数据库层的回滚操作可以直接用 @Transational 注解， 而关于IO流的操作属于OS层的操作，需要手工编写工具类进行回滚。 如发生异常后要对已经生成的PDF文件或签名图片进行删除。
四、总结
技术难点其实并不多，也不太难克服。主要是开源组件的使用熟练度，I/O流的运用、OS层面操作的手工回滚、数据库的设计和业务逻辑的一些要注意的细节。但自己在做的时候还是遇到各种各样的问题，也算是对一些比较基础，偏细节性的知识的查漏补缺把。
