在接口设计中，有的时候会给请求的某个字段设置一个默认值，
比如某个列表字段默认值会设置成空列表、某个字段(一般字段)设置了默认值
之前我以为前端如果不给字段传值，就会取设置的默认值，或者前端传了null，默认也会取设置的默认值。
但是实际操作了一下，结果是：
目前还不太清楚这个是否经过框架或者别的逻辑干预过的结果。
就目前的情况来理解，给某个字段赋值null是一种主动行为，因为null本身是字段可以取的值之一，如果调用方主动传了null，意味着其期望该值为null。如果期望取默认值，则可以不传该字段。
我喜欢研究技术，我喜欢学习未知的东西，渴望达到自己的技术自由。至今我都怀念研究生三年在教研室和图书馆学习数学学习机器学习和人工智能以及看论文的那些时光。
可惜自从开始工作之后每天回来都是筋疲力尽，这两年过的浑浑噩噩的。虽然也学到了很多自己看书学不到的东西，但是那种每天情不自禁的想要继续看会上次没学完的东西的感觉再也没有出现过了。这两年我也尝试着梳理过自己想要继续在什么方面学习的大纲，却少有精力真正持续实践过。
之前一直听说程序员做技术总是会面临35岁这一道坎，工作的这两年倒是没有太多实际的感受，可能是因为我的同事基本都是超过35岁的人，和他们在一起工作有时能感受到一些安心感，我遇到一些不确定的东西总是不用担心没人请教。不过最近找工作的同事还是和我说外面依然会面临这个问题。是啊，即便不考虑企业的因素，我当然也希望自己能在年轻时变得更加牛逼，但是实际往往事与愿违，人生中总是存在很多遗憾，随着时间流逝，我也能感受到越来越紧迫的追逐感。
好在我的目标依然没有变，我依然热爱技术，依然愿意投入精力追逐似乎永远没法完全追上的前沿。希望不远的将来我能实现自己的技术自由。
公司使用CSE框架做微服务开发，在打日志时虽然可以设置单条日志的大小，目前是10240，但是对于网关这种会处理大体积请求响应的微服务，10240有时是没法打出完整的日志的。
并且公司使用的云眼日志系统，针对单条日志抽取的体积是不到1024的，所以过长的日志会发生截断或者忽略。但是这样并不利于分现现网问题，于是之前就想着可以针对航班搜索或者退改签查询这种可能体积会比较大的日志做一下压缩，打印出来，如果需要后续分析的话，可以解密还原再做处理。不过压缩加密的代价会影响处理效率，航班搜索好在有缓存，所以可实施性还有的考虑。
目前搜索了一下现成的方案，找到的就是使用zip和gzip压缩(我是想找成熟的方案，其他要么是算法题，要么是一些简陋的实现，理论上应该会有类似的需求，不过目前找到的可行的只有这一种)。类似于网关发送给供应商请求时做的处理，然后把压缩的文本再做base64编码，需要用时再解码解压缩。具体方案如下：https://www.jianshu.com/p/b3fd26d82fd7
经过测试，如果先对文本做base64编码再送去处理，文本长度大概可以压缩50%以内，如果不做base64编码直接送去压缩，长度大概在40%以内。而已经压缩过的文本，进行二次压缩是没有效果的。
补充个Cpp的实现，用多了Java，对这种需要自己手写的实现还是有点担心，没有成熟的库函数调会不会因为自己写的不好导致出问题。
https://www.cnblogs.com/t-bar/p/16506289.html