一叶障目， 不见泰山------要对整个数据流有非常清晰的认识，避免走入死胡同！

       俗话说： 一叶障目， 不见泰山。 很多时候， 我们缺乏全局上的整体认识， 在局部死胡同中瞎转， 耗费精力。  扯多了， 颇有点格局和细节的意味。

       最近遇到这样一个问题， 如图：

       从接入层开始， 我把数据"http://w.x.y.z/aaa"写入， 最终落地到data中， 随后， 我用查看存储的"标准工具"查看data数据， 非常意外地发现， 从data中读取出来的数据是“//w.x.y.z/aaa”, 非常意外啊！

       于是， 我便认为， 肯定是写的时候， 改变了"http://w.x.y.z/aaa"的值， 于是寻找证据。

       经抓包确认， 入接入层的数据没问题， 入逻辑层的数据没问题， 入适配层的数据没问题。  当时又觉得， 入存储层的数据不太好查， 于是就想当然地认为一定是适配层在写入的时候， 改变了"http://w.x.y.z/aaa"的值。

       可是， 在适配层，在所有代码中的关键点中（写逻辑）， 发现没有改动原串的代码， 那就加log吧， 看看哪里变了。 无奈， 适配层的逻辑还挺复杂， 这log要加到猴年马月呢？

       停停吧。 如果走在做错的路上， 那么停止脚步就是进步！

       貌似是思路错误， 走入了死胡同。 于是反思上述过程， 进行了一步关键的验证： 写入的时候， 入存储层的数据又没有变化， 用tcpdump抓出明文包， 发现写入的时候居然没有变化。看来， 写入的时候没有任何问题。

       那就是“标准工具”读取的时候有问题了， 再看看“标准工具”读取的流程。 原来， 所谓的“标准工具”是从上图中的线路2读取的， 不是从线路1中读取的。 而我知道， 读取的时候， 在适配服务中， 确实有调用一个远程服务------实现从"http://w.x.y.z/aaa"到"//w.x.y.z/aaa"的转换。

       原来如此！

       最开始笃定是写逻辑有问题， 最后的结论是读逻辑在捣鬼。 值得反思。 

       实际上， 很多时候都有类似的悖论。 这让我想起了前段时间的svn提交二进制库的问题：你说你提交了， 但怎么保证你真正svn ci了呢？ 不能仅仅看提交成功的提示， 而应该让人外一个人svn up一下， 看看是否有结果。

       值得深思。