年初开发CR的流程单据，增加对附件类型的支持，之前的实现主要针对图片这种类型，很少支持类似文档、压缩等格式数据。我刚接手这个React Native的开发，加之开发时间较短，于是这块功能实现交给了同事协助，二月份开始自己测试时，发现附件这个组件开发只是满足基本的下载与上传功能，未与单据中的附件信息进行结合调试，中间缺少很多东西，于是就被这个附件给牵扯了。   当时基于市场项目开发的路线进行开发，参考web端的附件信息流转的逻辑，不断增加单据中一些字段信息进行联动，最后的附件组件就成一个定制化组件。在文件选择上，我们使用react-native-picker组件进行文件选择，使用react-native-fs组件下载文件，使用原来的方式实现文件的上传，在修修改改中，完成了第一版的附件组件开发，顺利完成这个单据的整体开发。   在PM单据开发中，需要使用产品化的思路来开发单据，这个单据在原有的基础上进行产品化功能改造，开发前期一切顺利，很快就来到附件的改造，这个附件的上传和下载接口都是“产品化”的思想实现，就需要我对原有的逻辑进行改动。上传变动不大，主要是请求url的修改，下载从原有的url拼接参数的方式变成post请求+参数对象，就需要修改基础的下载方法。时间有限就照猫画虎的改造一个，测试后基本可用就提交到测试流程。白天在对单据上传和下载测试时，功能表现正常，在快到下班时候，下载的图片就开始缺失和乱码，加班仔细走查代码后并无什么逻辑缺陷，随即拉上同事一起走查也无发现。当天时间较晚就没再继续跟踪。   第二天白天测试又回归正常，但晚上再去测试就稳定复现，于是尝试在web端测试该功能，上传下载，果然让我发现了问题，web端同样会存在部分图片乱码，于是拉上后台接口开发同事测试，成功复现问题，走查接口发现问题出在附件的临时保存地址上。当请求到后台服务时，它会先去ftp服务器取出对应文件后临时保存一个后台服务器的文件夹中，最后完成相应业务就返回这个文件的二进制数据。这个临时文件夹的名字简单设置为一个固定名称，在网络繁忙时有足够的时间进行处理返回数据，但在服务很少调用且下载多个文件时，后台处理时间缩短，前后数据时间间隔较短，最后导致临时文件中的数据已经损坏，然后再返回给前端就肯定出错。   本以为附件功能较为完善了，殊不知前面才是开始，之后现场测试SR的附件功能，发现文件上传失败。观察现象发现是后台问题，拉上后台同事一问，最近没做修改，开始定位报错信息。发现是现场使用私有CA证书验证，而FS组件默认公有CA证书上传，上传问题算是告一段落。然后没过多久，下载又出现失败，再次日志追踪，发现是后台报错401，打印上传时的请求体内容，携带信息完整且可用。于是只能请求外部支持，层层找人分析，发现是网络防护升级，使用xmlRequest方式请求下载存在丢失header，修改成ip+端口即解决问题，更深层的原因没有再继续研究。外网防护升级同时导致不能快速请求数据，否则直接返回请求拦截信息。网络防护，防住了所有人，不知道附件还会诞生出什么新的问题。   这几次的问题处理，从自身代码角度上分析，存在着部分问题，但主要问题来自外部。有时候自己的事情弄的再好，一旦外部因素作用，很容易全部失效，我们很难不和其它事情产生联系。我们每一次在互联网冲浪时，数据能够快速无误的传递到我们手机，是一项需要多方面高度配合的功能，但凡哪一小点出现差错，也是不能被允许。