題主的問題很有代表性，尤其是對企業資訊化建設前期進行技術選型時，需要重點考慮。根據本人經驗，透過Java開發平臺做平臺開發時，建議關注以下幾個方面：

第一、統籌開發目標，關注系統架構設計，

如果你的目標是建設一個平臺，那就說明不是一個小專案，一定要明確開發目標（尤其是階段性里程碑目標）。在專案整體目標明確後，做好系統架構設計。系統架構設計不聚焦在Java開發平臺上，而是界定好平臺內部各個功能模組（或業務元件）之間的關係，確定通訊機制和訪問協議。如果是計劃建設的平臺規模較大（如：將來計劃使用者量上千萬，或後臺資料TB級別），可能還需要做好中臺建設（關於中臺的建設此處不再展開），但一個資訊化平臺至少包含以下幾個部分：

許可權體系安全體系資料訪問體系介面通訊體系基礎功能體系業務功能體系使用者互動體系一閃幾個部分架構如下圖：

▲通用系統架構

第二、儘量做到功能解耦，強化系統可擴充套件性

Java開發一大優點是可實現跨平臺執行，無論是Windows伺服器還是Linux伺服器，只需要安裝JVM和JDK即可，從而實現了開發程式和作業系統的解耦。但平臺建設最難的是業務功能的解耦。幾乎所有平臺都會涉及到安全體系、許可權體系、跨域訪問等問題。在平臺架構設計完善後，務必要將業務功能解耦，將公共呼叫的功能模組抽象出來，形成獨立的元件，尤其是涉及到後臺演算法和效能的元件，更需要從具體業務模組中抽象出來。在元件呼叫時形成固定通用的呼叫介面，可以使封裝後呼叫，也可以是程式碼級、工程級引用。這樣既可做到平臺業務可擴充套件，也增強了後續升級迭代的便捷性。

▲功能解耦示意圖

第三、用成熟的第三方元件，強調程式碼可維護性

Java另一特點是其龐大的開源體系，可以從GitHub上獲得巨量支援。通常我們可以引入第三方成熟的元件，以快速高效實現特定系統功能的效果。但引入第三方元件時，最好遵循開源和成熟的原則。以便在業務調整，需要修改元件涉及到的相關功能時，可直接修改元件相關原始碼。

另外，Java開發時養成良好的編碼習慣，增強程式碼可維護性也非常必要。尤其是平臺核心程式碼，最好做好註解解釋，並對版本進行控制，以便升級迭代操作。

▲Spring框架的核心程式碼示例

希望以上三點能幫到您！

平臺選型一怕當小白鼠、二怕服務滯後、三怕隱性收費，MyApps低程式碼開發平臺業已打磨17年，無論是產品還是服務都有保障！

MyApps是天翎自主研發的第四代視覺化低程式碼快速開發平臺，使用者透過拖拉拽配置式操作，即可快速構建出能同時在PC和移動端執行的各類管理系統，節約80%以上開發工作量！

天翎致力於將複雜的技術以簡單的模式為廣大政企賦能，縮短週期、降低成本、提高質量，沒什麼不可以！動手試一試，付出有成本的行動定能收穫驚喜！

官網有免費線上試用，你可以過去體驗下。

先說Java技術架構，嗯，符合的很多呀，天翎、聯科、紅訊、致博、Koala、引邁、企雲、無遠、慧正、起步......尷尬了，B/S架構、可拓展、支援多資料庫好像大家都不賴呢，除非樓主增加篩選條件，不然我沒法往下走了！

或者我自作主張給一些建議吧：

1、如果你重功能大於重UI視覺，那麼建議優選老牌開發平臺廠商，像廣州天翎這種，超十年行業耕耘，1200+功能點，技術絕對過硬，反之則建議選擇網際網路型平臺，例如簡道雲、宜搭，UI炫酷視覺精彩，基本功能也不賴！

2、如果你的業務聚焦在資料填報分析，那麼建議優選擅長表單的平臺廠商，活字格、雲表、狐表等等一堆表，基於類excel理念，對資料非常擅長，如果你的業務聚焦在流程，特別是複雜的中式流程，那麼BPM類開發平臺則應該優選，天翎、炎黃跑不了！

3、如果你的客戶主要是政務單位/事業單位/國企/軍隊，那麼信創工程的中國產化相容適配要求絕對不能忽略，據我觀察只有廣州天翎、北京炎黃和上海普元能滿足，其他行業就無所謂了，暫時沒那麼多條條框框。

好了，暫時打住，快速開發平臺選型的切入視角太多了，一百多家廠商列也列不完，有真正厲害的主，也有渾水摸魚的娃，只能溫馨提示大家一句：選型請謹慎，免當小白鼠！

現在java搭建平臺，碼雲和github上有很多腳手架工程，下來程式碼進行二次開發就行了。最開始可能是jsp和servlet，後來慢慢的spring一站式框架就行了，慢慢該沒springw+springmvc+mybatis,在到這兩年springboot的流行，加快了微服務的落地。而且用java構建平臺現成的方案有很多，網上有很多，值得你借鑑。支援java開發的框架也有很多，給你更多的機會選擇。

看你的描述應該是大型應用，老實寫程式碼吧，不要指望走捷徑，客戶隨便提個需求就能讓你痛不欲生，而且可維護性基本等於零！

如果會java的話，這個選擇沒有錯；

idea+springboot+shiro，熟悉這些技術棧就能開發簡單的專案了！

Github上有很多這樣的腳手架工程，如果是java類的，最多的是spring boot+mybatis+mysql了，如果需要許可權管理，目前來說spring security已經要好於shiro了，如果你的專案比較大，語言搜尋類的，可以使用elasticsearch一些github上都有現成的開原始碼

再說前臺，如果想快速整合的話，可以使用vue,框架可以使用element UI，網上也有一些大佬給出現成的解決方案

最後再說支付，這塊網上有現成的程式碼工具類，整合的並不多，因為可以需要申請，所以如果你想做啥具體的東西，可以在網上搜索方案

其實關鍵是前端，這幾年流行前後端分離，java技術棧已經收縮成了服務層 持久層和整合層，表現層已經讓給百花齊放的前端框架和工具。

這也許是一種進步 一種趨勢，但是這造成了開發成本飆升。

開發一個大型後臺管理系統，應該選擇前後端分離的技術方案嗎？

一、結合“開發一個大型後臺管理系統”這個約束條件 冷靜的分析一下該怎麼選：

什麼是後臺管理系統：後臺管理系統 這個稱呼 意味著這是一個B端系統，可以小到部門級應用（客戶投訴登記系統、辦公裝置臺賬系統），大一點可以是大集團級核心系統（500強保險公司客服、呼叫中心），可以是ERP、CRM、OA產品（SAP、用友、泛微協同），可以是一個B2C電商的商城後臺、支付閘道器管理控制檯，可以是Saas的管理後臺（Salesforce、Teambition、Jira），可以大到阿里雲控制檯。。。

什麼是大型：我理解大型系統是指功能模組多、互動複雜，而不是訪問量、TPS、資料量大；所以CMS、OA、ERP、CRM、阿里雲後臺、呼叫中心、各種管理系統 只要功能多都可以稱為大型系統，雖然他們體量和交易量可能不在一個量級。 另外大型系統基本等價於“維護週期長 需求不斷變更”，這個在後面維護成本部分闡述。

UI操作效率是最主要考核指標：B端系統產品都是用來幹活兒、管理、生產排程的，操作效率和方便性大於天。螢幕空間要充分利用 減少切換跳轉彈窗；快捷鍵效率遠高於滑鼠；SPA 多頁籤佈局有利於保持工作上下文和狀態；必要時可以滑鼠右鍵選單操作；功能選單操作提示要清晰易理解 減少培訓麻煩；在此基礎上 儘量少每一個介面上呈現的資訊量 只呈現最少的必要資訊 降低使用者認知壓力；

UI開發效率高維護成本低是關鍵考量因素：大型系統基本等價於“維護週期長 需求不斷變更”，因此在技術選型上必須要求維護成本低、學習成本低、招聘容易、元件化程度高程式碼簡潔。。。

UI顏值美觀度不是關鍵考量方面：介面簡潔大方 圖表豐富 資料展現清晰，這其實本身就是一種美——樸素實用的美。

瀏覽器相容性 看情況：Saas要求相容性高，內網系統內部系統可以強制統一瀏覽器。

二、前後端分離對於“大型後臺管理系統”弊遠遠大於利

大型後臺管理系統 其實還隱含等價於“業務邏輯複雜”！相對於C端產品，B端產品業務邏輯複雜得多。我不是說B一定比C難做，C有另外的難度（比如使用者體驗、比如競品之間的競爭更加激烈、比如併發量挑戰、比如做活動的需求頻繁。。。）。單說產品核心業務邏輯，B一定是更高的。

複雜業務邏輯的產品 一定不是單靠產品經理、BA或前端設計出來的，也不是不能做，但那樣的產品 在業務抽象度、擴充套件性、實用性方面容易往往存在先天不足（無意引起爭論 一家之言）。

解決的辦法其實很簡單：產品、美工、開發各工種人員密切配合 快速原型 MVP（Minimum Viable Product） 快速迭代 快速試錯，

全棧開發的效率 效果 要遠遠高於前後端分離；

這裡說的“效果”指的是趁熱打鐵和技術主觀能動性的效果。

那種“產品畫框圖 美工做設計稿 前端切圖 扔給程式設計師渲染模板”的傳統開發流水線，會徹底拖慢一個業務需求從想法到交付的週期 會徹底割裂整個團隊 會遺漏大量的上下文資訊 會增加巨大溝通成本 會徹底磨滅專案成員的參與感和對產品的歸屬感。

畫圖仔、切圖仔和碼農 按部就班像流水線擰螺絲一樣開發產品，絕對無法創建出一個有靈魂有靈性的產品！

更不用提前後端分離造成的開發、聯調、部署、定介面、維護介面的成本提高。

另外前後端分離也不適合專案型公司，因為專案週期有限 分離的團隊組建起來 磨合順暢就很耗時，專案結束後又解散，下個專案重複資源浪費。留守專案的人員配置不齊 導致需求變更和維護問題難以解決。

綜上：angular react vue基本意味著前後端分離的開發和部署模式，這已經在根本上決定了它們不適合“大型後臺管理系統”，原因 一方面是上面列舉的種種弊端，另一方面是大型後臺管理系統無法享受到前後端分離的好處：nginx分開部署的優勢、專業前端優勢（C端產品追求極致的顏值和使用者體驗）。

既然這麼多弊端 又享受不到優勢，為什麼很多企業（專案）跟風搞前後端分離 跟風上vue react呢？ 答案其實很無奈“簡歷驅動的開發”、“KPI驅動的技術選型”。

三、切忌“簡歷驅動的開發”、“KPI驅動的技術選型”

軟體開發絕對是個良心活兒，跟醫生 教師。。。一樣的。

我這幾年見到了太多的微型團隊（10人以下）搞微服務架構，百萬級資料量的大資料專案，以及前後端分離的CMS內容管理系統！

見了太多為了用時髦技術而盲目選型的事情，太多不計後果不計成本的追求新技術來美化自己簡歷，太多用流行技術名詞忽悠自己不懂技術的老闆 上司的情況。

你們的良心不會痛嗎？

當你在簡歷上加上了一個個流行技術關鍵詞，然後拍拍屁股離開了一個爛尾的專案 一個預算嚴重超支的專案 讓創業團隊多走幾年彎路甚至夭折，你的良心和職業素養都破產了！

你正在透支技術人這個工種這個群體的社會聲譽。

技術人的天職 本應是把複雜模糊的現實世界問題 建模成清晰邏輯結構化的計算機軟硬體，讓世界變得更簡單高效，如果因為一些奇怪的原因而把簡單問題複雜化，那就是背離了這個行業的初衷。

希望越來越多的甲方、非技術出身的高管們明白一個道理：靠譜的人是把解決方案做的很簡單以至於明顯沒有問題，不靠譜的人會把解決方案做的毫無必要的複雜以至於短時間內看不出明顯的問題。

前後端分離不是壞的，跟風才是壞的

前後端分離的出現和存在，當然有它的合理性和優勢，看看誰創造了它們——谷歌的angular、facebook的react、阿里的antd、餓了麼的element、前谷歌程式設計師尤雨溪建立的vue。

但是簡單看下它們建立產生的背景 當時的初衷 後來的成功案例，不難發現 這裡面其實還沒有erp crm這種典型的B端大型複雜系統。

所以我建議 至少不要不加思索的就把前端選型的候選人圈定在這三個當紅花旦，不要覺得跟著網際網路大廠走就一定不會錯。

彼之良藥汝之砒霜，你要搞清楚你自己是什麼樣的定位！

網際網路大廠 獨角獸 前沿風口上的明星產品很多情況下都是資本遊戲 燒著風投的錢 靠補貼做活動 砸廣告費引流做出來的資料 把估值做高找下一輪風投接盤。如果你是這種情況 那沒的說，儘管選最好最貴對標一線大廠技術棧 甚至人都是各大廠挖來的。

如果你們是做專案賺辛苦錢 或自己投資研發產品，在傳統方向在產業網際網路精耕細作 慢慢摸索培育市場 不在風口不受風投追捧的，那我覺得你們需要務實一些。

我建議各位本著務實和誠實的態度、職業精神操守，結合自己公司 團隊 專案 業務需求，選擇最適合自己的技術棧。

問題還是回到“開發一個大型後臺管理系統，應該選擇前後端分離的技術方案嗎”？

我對java開發為主的公司和團隊 推薦一個東西：ZK（The leading enterprise Ajax framework） 純java的企業級前端框架。

https://blog.csdn.net/daquan198163/article/details/9304897 https://www.zkoss.org/