公司的OA系统处理一个历史由来已久的问题，花费了1个多月时间排除，终于还是把该问题解决了。这才知道，这问题其实是自系统上线以来就存在的问题，并且当时没有及时发现，一直延续至今。

    现象：

    不确定时间、无固定规律的从前台页面提交到后台的数据会未知原因的丢失，丢失时该字段名在存在，但字段值丢失为null。

    问题排查：

    起初怀疑前台页面没有填写数据导致的，后添加后后台调试代码，发觉取得的值为null（这不可能，前台传递的字段即便不填也应该为空字符串。）。另外发现一个问题，当后台因提示必填项未填写而抛出的异常时，刷新提交有时候能够提交成功。这就是说明，有时候数据会丢失。

    看看项目的框架，使用公司自制的MVC框架，使用Post提交方式，使用multipart编码格式（以支持附件上传）。于是乎有个想法，使用非multipart编码的post提交方式是否存在相似情况。看了看公司的MVC框架，普通的application/x-www-form-urlencoded编码格式是在框架中直接存储request对象的；而multipart/form-data编码格式需要判断是否为字段，并且从中进行筛选字段名和字段值存储到一个对象中，而非字段则进行文件上传操作。

   当把这个没把握是否有成效的“在正式环境中去掉multipart/form-data编码方式”的调试提议上报个直接领导时，她不同意，认为不该在正式环境中做没把握的瞎搞。（当然，我知道风险就是，使用非flash的普通附件上传的用户，无法正常上传附近。）

    经过了一段时间对其他可能性的研究，依旧没有进展。心中对那个multipart/form-data编码方式的疑点一直放不下。以前的电脑维修经历告诉我，不该放过任何一个可疑点，不该放过任何一种可能性的尝试。终于还是憋不下，悄悄找了系统管理员，告诉他我的想法，以及带来的风险，并且愿意对问题带来的风险负责。我平日的工作态度让他充分相信不会整出大麻烦，于是下班时允许我悄悄改了5台正式环境的其中一台的该页面multipart/form-data编码方式。

   第二天，我有点忐忑的索要了昨天修改了页面代码的服务器的日志，发觉……自那之后系统的字段值不再丢失了。为了确保问题的正确性，有让系统运行了几天，发觉问题终于消失了。这回找到原因了，这是持续4年多的历史遗留问题！高兴的，兴奋的~。

    这次排错历程告诉我：

不能放过任何一个可能性；

在充分估算风险之后，在风险可接受的前提下，应该大胆去尝试（风险与机遇并存）；

太过听从领导或者权威的话语，有时会遏制你的思维。应该对权威加以筛选和分析；

正确坚持自己的直觉和质疑。正确坚持自己，是自信的体现，同时又不盲目固执己见。直觉有时候是知识沉淀的无意识状态爆发来的，质疑的情绪化能够让把事物看得更加清晰；