不管你寫不寫 JSDoc，JS 的介面都是非常動態的。函數同樣可以使用 arguments 和 call 等動態方法傳入各種不同的參數格式，甚至可以不符合接收方的參數清單。

在文件產生方面，JSDoc 確實可實現快速的文檔產生。但這對程式碼模組的組織模式、註解的長度和開發者的水平都有更高的要求，且自動產生的文件通常可讀性不如直接維護的來得好（反例如Yeoman，自動產生的文件一大半在處理莫名其妙的繼承關係）。

在提升開發體驗方面，編寫 JSDoc 確實能夠提高 IDE 進行程式碼提示的智慧程度，也能夠配合 eslint 在開發 / 編譯（打包）階段發現潛在的問題。

追加一點，在重構程式碼時，經常遇到的一個問題是【在運行到這裡時，這個變數應該是什麼類型，這種狀態下取什麼值？ 】由於前端和後端實際上都是在圍繞數據編程，因此若使用非常動態的數據類型且缺乏文檔，那麼在維護或重構代碼時，會發現經常難以理解【函數到底輸入了什麼，返回了什麼】，而JSDoc 可以有效改善這一點。

不過，個人猜測題主真正想問的是：【既然 JSDoc 有這麼多好處，是否應該在我的業務代碼中使用這一功能呢？ 】

這個問題和【我是否應該寫單元測試】實際上是一類問題。大家都知道寫單元測試和 JSDoc 有不少好處，但問題也非常明顯：它們會增加程式碼量和開發週期長度。和單元測試程式碼在單獨的 test 目錄不同，JSDoc 直接增加了業務程式碼長度（除非你使用 TypeScript spec 等新 Doc 手段）。因此實務上對復用性不高的業務代碼，不寫JSDoc 或單元測試是完全沒有問題的（答主在若干也不算小的廠混過日子，各家前端的實際業務代碼都是以實現功能為第一位，不寫成麵條程式碼就不錯了，哪裡還有時間給你加囉嗦的文檔？各自的規範的）。而在你造輪子，發布一些可重複使用的程式碼模組時，完善的 JSDoc 和單元測試有利於模組的可維護性，也能讓使用者感受到【程式碼品質確實不錯】。

簡單說，JSDoc 造輪子時就上，業務代碼早點乾完不加班最重要，不要自找麻煩。