Qt如此強大為什麼就是火不起來呢？

01-13

舉個例子，Qtdesigner中直接就有日曆控制項，拖過來就能生成一個簡易日曆軟體了。Qt真的很強大，但為什麼就是火不起來呢？跟開發出它的公司不出名有關嘛？

用Qt已經4年了，我來說說感受。

在我用Qt的這些年裡，Qt一直處於不溫不火的狀態。有很多公司用，如YY、WPS這樣用戶過億的產品，也有不對普通用戶的軍工、船舶。最近在汽車這塊也比較火。但是Qt沒有在被大規模的採用，往往是只有部分行業內Qt的使用率很高，這的確是事實。

Qt是我的主力開發框架，我拿Qt開發了客戶端，伺服器端，桌面端，移動端甚至還包括點嵌入式端。這這之中我遇到了很多Qt的不足以及Qt的強大。考慮到題目定義，在本回答中我主要講不足。

0.互聯網時代了，很多人已經答過這個，不展開了。

1.開發人員不足：這是我現在發現Qt這個生態系統里最大的問題。因為缺少開發人員，導致企業難以招到高質量的Qt工程師，然後不願意展開Qt的項目，這簡直就是惡性循環。我見過有公司因為擔心招不到Qt工程師，直接把已經做好的產品雪藏，再用HTML5重新開發一遍。

2.工程師們對Qt認知普遍落後：直至今天，Qt從4.8開始推出的QML（QtQuick框架，計劃是代替QtWidgets）仍然沒在Qt圈子裡普及，甚至很多人都不知道這是什麼以及這個能幹什麼，這更別說其他工程師們了。

3.學習成本高：Qt有QtQuick，這個開發起來非常方便，但是這畢竟是新的框架，帶來了新語言和新的開發模式，這意味著學習成本，很多人看到就望而止步，拒絕學習（沒錯，是拒絕學習），我本人也是在接觸Qt兩年後才慢慢接觸這個框架。才發現這是好東西。退一步說，就算是只用QtWidgets，這也是C++，這個入門成本太高。套用我以前同學和我說的話：如果我學的是Web開發，我第一天就可以做出可視化的成果，用起來還不錯。但是如果是C++，幾個星期了說不定還是黑乎乎的控制台，學習的興趣一下子就沒了。

4.硬體要求高：我認為Qt的未來在於QtQuick，無論桌面、手機還是嵌入式。但是QtQuick對硬體要求很高（相對QtWidgets而言），沒顯卡，或者顯驅不完善，不好意思，直接拜拜，跑不起來。很多公司因為這個，放棄了QtQuick，回到QtWidgets，去糾結那個C++到底適不適合開發界面的問題。甚至直接拋棄Qt。

5.太大：一個HelloWorld 10多MB，我覺得這個正常，畢竟Qt不是系統級別的庫，但是很多人接受不了。另外Qt自己也出了lite計劃，降低Qt的大小以及對硬體的依賴（一起解決我說的4、5兩點），但是截止我編寫本答案，該項目仍在開發中。

6.宣傳力度低：舉個例子，Qt以前就有一個虛擬鍵盤的組件，但是只給企業版，然後前段時間給開源了。但是我問過很多很多人，他們連有這個東西都不知道，仍然自己在造輪子。還有其他很多東西都是如此。其實這個來源的信息都是公布到官方的blog，但是是英文，很多人估計都不會去看一下。

7.授權協議：目前Qt是GPL和LGPL，這個就不用我詳細解釋了吧，動不動就要開源。除非買企業版解除這個限制，但是企業版又是一個大開銷。

其實啊，我還是挺喜歡Qt的，千萬別說我在黑Qt。

結論：Qt的前途是光明的，但是道路是坎坷的，Qt加油。

1、題主說到點子上了——Qt沒有個好爹。從最早的TrollTech，到後來Nokia，再到Digia，現在甚至獨立出來自己上市了……

什麼叫做好爹：

紫色史詩級好爹——能夠制定標準，如Mozilla
橙色傳說級好爹——自己就是標準，如Microsoft、Google

顯然Qt前後三個爹都不夠格……

講真，Qt如果有個好爹，元對象系統和信號槽早進cpp標準了。元對象可以實現反射，而且對象內存依舊緊湊，直接代替type_info作為typeid的返回值。這倆一起放RTTI里，多完美。

2、C++本身就不火。C++領域內Qt算是很不錯了，有GUI的地方都有它，有嵌入式的地方一般也有它，然後金融、工業、遊戲、多媒體這些行業也有它。就如 @姚冬大神所說，Qt在C++領域已經相當火了，但架不住C++本身不火，現在是互聯網的天下……

Qt 還是挺火的，至少在行業軟體領域還是很火的，我認為 Qt 應該是當下最火的 C++ 框架。

在嵌入式領域 Qt 處於統治地位，比如據我所知，大量的醫療設備使用 Qt 作為 GUI 框架。在桌面端，國內知名的消費軟體 YY、WPS 都使用了 Qt，還有一些桌面 webkit 內嵌應用也是用 Qt WebEngine 開發的。

另外我說一個大家可能不了解的行業：安防監控。

安防監控領域對 Qt 的使用相當廣泛。在國外基本上是 Qt、WPF 分庭抗禮，在國內，早年間以 MFC、delphi 為主，幾年前，大廠商已經全面轉向 Qt。比如海康威視 iVMS 系列，大華技術 DSS 系列軟體平台，目前絕大部分界面基於 Qt 實現。

在這個領域內，國內有兩家市值百億美金以上的大企業，另有若干年產值 10 億人民幣以上的中型廠商。所以如果你喜歡從事 Qt 開發，又找不到滿意的崗位，去安防監控領域試試，機會很多。

你想要怎樣火？

Qt只是成千上萬的C++ Framework/Library之一，舉辦個開發者大會能來上千人，而且每年在世界多個國家舉辦。

你幫我想想還有幾個這樣的 Framework/Library？

大家應該關注一下黑莓qnx系統的重新興起。

這個系統基本只能用qt開發。

從事前端十來年，簡單說說目前幾個主流fw在本行業的特點（無責）：

1.flash/flex/air:

優點：簡單；高效；可視化；跨平台（除了ios）；十幾年的積累各種成熟類庫；可以拿來做快速生產；特別是簡單交互類的項目！！！！

缺點：adobe放棄治療了；底層操作不多；如果做大項目則需要有豐富的優化經驗，否則絕對是挖坑。

2.winform/wpf/uwp:

優點:非常適合做軟體；性能不錯；底層操作性強；語法不反人類；語法糖加持；成熟類庫非常多；大學有c#課。

缺點:容易被雅黑；nuget被牆，需要vpn；手機無望；個人認為非軟體項目不是最優解。

3.xamarin:

優點：具備1和2的優點而且沒有1和2的缺點。

缺點：智聯招聘關鍵詞一下。

4.qt:

優點：跨平台；性能好；可以用js搞；ui相關功能非常強大，基本不需要找第三方庫；特定領域有優勢；qml和示例對新手友好。

缺點：qml不是萬能的，一旦需要在qml中調用qml做不到的事會很麻煩；js和c++各有利弊；非主流的設計思路可能會讓你難受；英語不行請放棄；不會翻牆請放棄；另外智聯招聘看看待遇，給我一個不學java大數據。

5.node.js

優點：未來之星；做軟體請用electron，做交互請用白鷺，可桌面可移動；上手容易；ts能夠彌補js的很多不足；大量成手設計師和開發者；

缺點：需要有人帶你掌握各種構建工具；如果你在非互聯網公司（尤其是上網管制的企業）工作，請考慮pass。

6.java

還是去做大數據吧。

每種技術都有他的優缺點，一定要根據項目和公司技術積累的具體情況考慮，不要盲目追新，但也不能一味守舊。

最後一句話：存在即合理。

1. Qt 目前還是蠻火。只是互聯網時代了，火大不起來。

2. C++做軟體，在於小而美且快，Qt一搞就大了，大了讓大家都覺得美就很難，大了也快不起來。

3. Qt作為一個庫，一直在追求大而全，無所不能。這是它最大優點也是最大的弱點。

4. 親媽的確不咋滴，後媽更不咋滴。作為一個庫，是否出生名門很重要很重要很重要啊。

PS：名字是Qt，不是QT或qt或qT，樓上說錯的，都應該燒死燒死燒死...

因為QT在UI重要的系統裡面都干不過原生的系統，只有在鄙視UI的系統大放光彩（

我前幾天寫過一個答案：

如何評價 Qt 的發展前景？ - 知乎

Qt 是很有價值的工具。用了之後如果過段時間覺得不能滿足項目要求再考慮逐漸棄掉也並不困難。但是缺乏粘度加上不是原生終究不利於自身的發展。

另外針對你的問題，我要強調的是「拖過來就能生成一個簡易日曆軟體了」這件事情，大概一年裡也就做上兩三次。這個功能做 demo 很吸引人，但是對老手完全沒有意義。否則你的 app 的功能也就太低水平重複了。某個 SDK 可以沒有拖控制項的功能，我可能要多花半個小時來調試初始的 layout，但是這個弱點對我來說並不是致命的，因為我可能三個月才需要做這一次。而我這三個月里要完成的其它任務才體現 SDK 對我的主要價值。

所以，拿這個來感受 SDK 的強大說明你的感覺方式不對。

之前我跟周圍的人一直都是Qt ( [kju?] [ti:] )這麼地叫著。

最近突然才知道正確的讀法是Qt ( [kju:t] ) ( 和單詞cute的讀法一樣 )。

我問了好多人，發現大部分的念法都不對（也可能是我周圍的人或者朋友都像我一樣low）。

也許把大部分人的讀音糾正一下就能火起來了？→_→

Qt長著一副C++的高性能臉，卻有著一顆比Java還OO的心。（

我delphi都沒叫屈，你Qt反倒來叫屈？

個人覺得普通應用web ui就不錯,比如jqueryui，extjs，bootstrap，react等等，界面開發效率吊打qt，wxwidget，mfc等等。比如一行input就添加一個button，各種css樣式，還不用編譯。什麼？wpf/flex，這兩個貨還活著嗎？微信windows客戶端不是基於libcef嗎，多方便啊。優酷pc客戶端以前基於flash技術做界面，現在改為基於qt.webview做界面，約100多兆程序，c++寫的，要我說還不如electorn直接開發，只需要js程序員，省下c++程序員工資。什麼？webui運行時體積大，不要緊，這年頭不怕這點硬碟，你家qt載入qwebengineview不也快100兆了。什麼？吃內存，你家安卓上跑java虛擬機，你不也耍的很開心嗎？個人覺得qt將來發展前景不明朗。要是開發3d遊戲就當我沒說

Qt只有在操作本地硬體相關的系統上才說得起話，比如一些醫療儀器，工控儀器，智能家居(自從有了安卓，智能家居也用不上Qt了)。業務應用的話，web更好，用戶無需升級客戶端，打開即用，跨平台效果好(Qt僅是一個公司及個人維護跨平台，web可是有國際標準的)，開發效率高(一個剛畢業的前端一天能寫十幾個頁面，帶效果。Qt能比？)。所以Qt只適用於一些(和硬體相關的)專業領域。

應該是desktop開發現在越來越不行了。

現在是app，web，和混合開發當道的時代了。

wpf這麼好的東西也是玩了，基本沒啥更新了。。

qt確實好用，比mfc強100倍，可惜所處時代變了。。

c++學習成本本來就很高，再來個二次封裝，Qt想學好太難

我想說的是：悶聲發大財，誰用誰知道

主要是它以及C/C++擅長的領域不火了。我們主要關注消費軟體，如果把目光放在行業軟體領域，還是很多的。

用C++快十五年了，用Qt也快7年了。怎麼說呢，這個東西其實在linux下還是超級棒，主要火不起來，就是沒有伺候好windows:

一是win下環境搭建難。很多軟體不光是要qt的，還用了好多別的庫。如果qt恰好沒有和幾個關鍵庫相對的編譯器版本，那恭喜，自己編譯吧。特別是在win下，儘管出了msys2 這樣的傻瓜神器，但想搭起來一個生產環境還是一門學問。

二是程序依賴多。動態鏈接，一個程序拖著好多庫，還有插件子目錄，嚇死人。若是靜態，恭喜，自己編譯，搞定資料庫驅動等東西。發布時，一堆文件，倒是顯得軟體牛啊，因為大啊！！哈哈！

三是版本兼容差。這是C++程序的通病。如果是C的庫，只要介面不太變，二進位兼容性還是有的。這C++ ,類稍微變一變，dll就不兼容了，一堆崩潰。這種會在path環境變數被污染時要命。記得以前客戶的計算機里就是跑不起來，最後一看，他把wps的路徑加到path里，結果qt版本不同。

不過，作為一個資深行業軟體攻城獅，只能說，我忍了！在很多領域，庫都是C和C++的，綁定了語言，有了他，省了不知道多少事！

老外也有這樣的疑問，然後一堆人回答，這是其中一個最高票的為什麼不用QT的回答：

原地址： Why aren"t more desktop apps written with Qt?

I don"t really intend this to be a bashing answer, but these are the reasons I do not personally use Qt. There are plenty of good things to say about it -- namely that the API works most of the time, and that it does seamlessly bridge platforms. But I do not use Qt, because:

In some cases, it just doesn"t look like native programs look. Designing a single UI for all platforms inherently is not going to look right when moved from machine to machine, for various visual styling reasons. For example, on Mac machines, split bars are usually relatively thick, and buttons are small and rounded with icons. On Windows machines, split bars are typically narrow, and buttons are more textual, with more square designs. Just because you can write one UI for every platform does not mean that you should for most applications.
Qt is not a C++ library. It requires a separate compilation step, which makes the build process much more complicated when compared with most other libraries.
As a result of (2), C++ IDEs and tools can flag Qt expressions as errors, because they do not understand Qt"s specifics. This almost forces use of QtCreator or a textual only editor like vim.
Qt is a large amount of source, which must be present and preinstalled on any machine you use before compiling. This can make setting up a build environment much more tedious.
It"s available only under LGPL, which makes it difficult to use single-binary-deployment when one needs to release under a more restrictive or less restrictive license.
It produces extremely large compiled binaries when compared with similarly written "plain ol" native applications" (excepting of course applications written for KDE).

你要是還用過其他語言/框架寫GUI你就知道Qt有多蛋疼了