總結一下，自己對前段項目結構的構建。
匆忙寫下，后續修改。
對於前端的各種風格，我倒是沒有什么所謂，每個人有每個人的風格。我比較在意代碼的結構，代碼的結構清晰，更容易幫助人理解業務邏輯，而不至於陷入各種api的調用使用中無法自拔，api使用不合理，倒無所謂，每個人都有自己的欠缺，有些知識不夠深入，就容易api使用不合理，但是，客戶端的性能很強大，這些東西在前期都可以暫時性忽略。
1、唯一入口。
每一個頁面都有一個唯一的入口，即，從文件夾，css，js，html都是從一個入口進入，往深入擴展，讓整個結構看起來像一棵樹，一層套一層。這樣，在無形之中，自己就會將代碼寫在合適的地方。下一個接手的同事，在梳理代碼的時候，更容易熟悉業務邏輯，在不是很熟悉的時候，也會將代碼寫在合適的地方。
2、靜態文字，資源的管理。
從國際化角度來說，所有顯示在頁面上的文字都應該抽離出來；所有接口的調用地址，也應該獨立存放，根據上面的唯一入口原則，當項目非常大的時候，可以折疊，查找維護起來會更加方便。
3、動態數據的管理。
在前端構建項目的時候，大多時候都是先寫好靜態頁面，寫好交互，再接入接口；后台版本迭代過多的時候，也可能會重構項目，將很多冗余數據，字段去除，整個項目重構，后台重構，往往前端也要跟着重構，這個時候就可以將動態數據靜態化，意思是，前期構建好的項目，需要的數據，封裝成一個JSON，通過一個格式化數據的js文件，轉化過來，之后所有通過接口返回的數據，都通過這個js文件，轉化成前端說需要的JSON結構。即，ajax ---> js文件 ---> JSON ---> 頁面數據。往后，后端重構，前端樣子不變，或者結構不變，我們只要在js文件中將后端返回的新的數據結構，轉化成為之前的結構即可，將整個項目的交互和動態數據解耦。
4、不同頁面交接，入口分發式。
現在很多項目都是spa，spa很大一個問題是首屏加載，而更多時候用戶是過路式使用，即，只用之中一個功能，用完就走，例如打卡，打完卡就直接關閉頁面（沒有想解決這個問題）。比較常見的處理方式是：按模塊加載，即，打包的時候將每個模塊打包成一個js文件，就減少了首屏加載的一部分問題。在不斷的迭代中，需求發展着很可能會讓多個模塊耦合在一起，隨着版本的迭代，在項目的某個部分公用多個地方，又不能抽離成組件的時候，整個項目版本迭代過多之后，大多會變得不可維護，難於維護，特別是趕時間，寫了代碼沒有時間去重新整理，就需要一個公用耦合頁面入口進行分發，以后維護，還是交接時，都知道應該在哪里寫代碼。
5、第三方組件，二次封裝。
現在提倡的模式是敏捷開發，各種npm，各種UI庫。剛構建項目的時候，用得很爽，抬手間就將項目寫完了。但是，現在定制化程度很高，產品經理需求也更多，更加想象不到，用着用着第三方的UI庫，特別是多個地方用上的時候，並且UI妹子沒有組件化思想，一點點改動的時候，UI庫的組件就會變成非組件，最后統一組件的時候，就會發現一個殘酷的現實，某些組件寫着寫着變成了另一個組件，某些本來不是組件的，寫着寫着變成了組件（寫代碼沒有組件化，別人罵你，你還不能反駁），當某些某些組件變成了新的組件的時候，處理不恰當，新組件跟業務會耦合在一起，如果沒有足夠的時間梳理，那么，最簡單的方法就是拷貝。。。從此，再無組件。
6、本來不是組件的，寫着寫着變成組件了。無解，求搭救。
本文原創，不允許轉載，如有問題，歡迎探討。