P粉9868609502023-09-05 12:44:28
你是什麼意思？
在這裡，我們只談論頁面，對嗎？所以是/user/id，/post/id等等？
如果是這種情況，你可以有一個/_entity/id，甚至是一個/_entity/_slug，以獲得更大的靈活性（_entity可以是user或post等等）。
如果你有很多不同的頁面，例如/about，/our-team，/careers等等，我想這些頁面都需要有自己的SEO 、內容，而且是完全合法的。
我真的不明白為什麼這會成為一個問題。它將被正確組織、可擴展，並且不會有太多的抽象（在我看來這很重要）。
你也可以透過nuxt/content將其中一些頁面匯出為.md文件，並將其匯入到頁面中。就像Nuxt文檔所做的那樣。
如果你真的需要簡化這些頁面，你可以讓整個模板動態化，並在運行時產生標記。這可能會引入一些巨大的複雜性，可能並不需要（在我看來）。
此外，佈局、插槽和渲染函數也可以是一種解決方案。
我不確定微前端（對我來說聽起來像個炒作詞）實際上是Nuxt的幾個實例相鄰放置（如果在同一域名下託管的話聽起來像個可怕的想法），還是你的非單體全端應用的「組件化」（幾年來我們建立網站的方式）。
但對我來說，如果一個專案有100個pages，完全沒問題。
當然，硬編碼一些/blog/post/1，/blog/post/2是不好的（哈哈），但一個大型應用程式完全沒問題。這可能會在建立時間等方面引發一些問題，但這是另一個主題，更取決於你產生專案的方式。
所以，是的，如果你的面試官想要深入了解這些方法之外的東西，你需要從他那裡獲得更多細節，以確切了解面臨的挑戰和可以使用的方法。
簡而言之：據我所知，沒有框架旨在減少頁面數量，因為這本身不是一個問題。 10k個Nuxt頁面不會以任何方式使你的/about變慢（如果確實如此，問題在其他地方）。