“我本地是可以的啊，爲什麼生產上就不行了？？？”
上面那句話相信大家都有說過，現在似乎已經被戲稱爲“程序員最大的謊言”，呵呵……我就來以我個人的遭遇來總結下教訓。
場景一：單獨把自己在本地編譯無誤，測試無誤的類編譯成class文件放到生產環境。
大部分情況下我們都是這麼做的，本來在本地跑得好好的代碼，上了生產死活跑不起來，而且還不報錯……
我碰到這種情況的時候，是因爲我在本地的該class文件對應的java文件裏，註釋了暫時還不需要上線的方法A，而方法A又調用了方法B，方法B裏的代碼涉及到了還未提交上線的其他類或方法。雖然在我本地編譯無誤，也生成了一個class文件，新功能的調用者方法A我也註釋掉了，但是直接把這個class文件放到生產環境其實是編譯錯誤的。因爲生產環境的class文件還沒有你的方法B裏未提交的類或方法……
辦法是提交你的代碼，由負責升級打包的組長更新，他的對應的Java文件肯定是編譯不通過的，因爲方法B編譯未通過。因爲你還暫時不能提交B，所以他刪掉你新加的（還不需要上線）功能方法A，以及它的依賴方法B，再重新打包成class文件即可。
以上，就要求到我們升級打包的規範性操作。。這種潛在的錯誤是很容易犯的。
場景二：確保本地環境和生產環境的jdk版本環境是一致的，因爲不同jdk版本，對一些語法的支持略有差異。
場景三：本地一般是單機環境，生產環境大多數情況下都是負載均衡的，當一些緩存數據在啓動的時候需要保存在內存中的時候，重啓該臺機器會清空內存中的緩存數據。而如果需要讀到該緩存數據，當還沒初始化完成時，往往可能造成NullPointerException（因爲初始化到緩存中需要一定時間。）。若希望不受重啓影響，建議把緩存數據存放在nosql數據庫中，如redis, mongodb, cassandra等，這樣多臺機器就共用同一個緩存中間件，任意機器的重啓並不會造成緩存數據被清空，而讀取緩存數據的·時候就改由從緩存中間件中讀取而非內存中讀取~~ 項目啓動的時候初始化緩存最好採用異步的方式，而不是用線程阻塞的方式。。
場景四：針對同一批數據重跑，指望跑出的數據覆蓋原數據，結果發現重複。——排查表的主鍵是否是自動生成策略生成。
=====================持續補充=========================