最近一個朋友瘋狂的和我吐槽公司的后端，說很常規、很普通的一個事兒，也就是驗證一下子的事兒，非要搞的那么復雜，治標不治本，技術玩來玩去不但沒進步還倒退了。

這是怎么回事呢？咱們就來聊聊這件"小事兒"，大家可以看看自己內部是怎么做的。

咱們都是搞前端的，所以和后端打交道最多的就是調用后端接口獲取數據,每個公司應該也都有自己的接口規范，傳參規范等。

我這朋友的問題是這樣的，前端請求接口，帶過去了一些參數，但是其中有個參數沒值，也就是空，但是呢后端在接收該值的時候沒有類型判斷(該字段是int類型)，相當于直接把一個空字符串直接轉為int類型。結果可想而知了，肯定是出異常了。導致業務上受到了影響。

比如,請求參數如下

name=bigerfe&age=&a=1

其中參數age是int類型，但是前端傳了空，后端取參數的時候報錯了。

此時，前端理解的是后端只需要后端做個容錯處理就可以了，轉化失敗就給個默認值唄。但是后端理解的不太一樣了，希望前端如果是沒值的這種字段，就直接不要拼接到參數里，這種空串對于我們來說是沒意義的，沒意義的就不需要拼接了。然后要出一個傳參規范，聲明string類型的字段如果值為空串的，請求的時候就不要攜帶該參數。其他類型的會給一個默認值。

比如這樣,age字段干掉了

name=bigerfe&a=1

我這朋友不樂意了，覺得這不合理，認為本質問題就是兜底處理沒做好，怎么扯到規范上來了，覺得這個規范對他們的影響挺大，需要改代碼，不能接收這個提議，但當時也不能說出一個更合理的理由，只能忍著。

其實我們客觀來分析下，解決這個問題的最簡單的方法就是后端做好容錯處理，轉換失敗給個默認值，提到規范層面也不是不可以，但是要先明確問題產生的原因。

既然要做規范，這也是好事，這樣各端就都統一了，也能讓其他端避免再出現該問題，若遇到什么問題，不清楚的直接去查規范就好了。

如果后端初定了上面這樣的規范，然后和大家一起討論，看是否可行，如果你覺得不合理，你該如何反駁呢？

既然你覺得不合理，你覺得怎樣合理？

有時候你覺得不合理，可能是你不想做，你沒有這樣的習慣而已。

你可能會說，不攜帶這個參數和傳空串完全是兩個意義。

如果是你遇到了這個問題，你該怎樣處理？接受還是反駁？能不能找到一個走不通的場景？

。。。。。。。

畢竟該規范是不合理的，人多了總有人能想到不同的場景，在團隊的討論下，結果該方案沒有通過，還是保持原來的方式，不會干掉這個字段。

接口規范中為每個字段說明其類型，并且給出默認值

服務端做統一的類型驗證，不符合的直接給出錯誤碼

那是被什么樣的問題給拍回去了呢？

如果這個字段是必填的，而且是空串，那這個字段可以帶嗎？你給什么默認值？

比如我在后臺要修改某個人的信息，改為空，怎么辦？走不通了吧！

好了，別的不多說了，可能還有其他的場景，大家可以留言來討論。

最后，有時候我們可能覺得某些方案不合理，但是一時也想不出去為什么不合理？其實也能做，但就是不想做，可能成本高，影響范圍大。但如果真的不合理，那一定要拿出不合理的理由，或者在某些場景下走不通，而不是通過經驗來說這樣不合理。另外，有時候一個人想不出理由也很正常，所以這個時候就需要團隊一起來討論，把方案拿出來，合理不合理很快就見分曉，畢竟一個人的力量是有限的，人多了想法多，思考的角度也不同。通過討論才能有更好的結論，這可能也就是團隊存在的一個重要意義吧。

另外我們自己也不能處處依賴團隊，時刻應該調整自己思考問題的方向和思路，當遇到不合理的方案的時候，不要陷入代碼層面去，也不要只考慮自身的工作量，更不要被以往的經驗和習慣給束縛了，應該跳出代碼，多考慮業務中的實際場景，看是否都能滿足。

點贊是最大的支持?

總結

以上是生活随笔為你收集整理的分页携带请求参数_一个值得深思的小问题 请求中的参数值为空要不要携带该参数？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。