我遇到了其中一個不一致發生的問題，因此即使對我來說也很難複製。
我有一個 4K (3840x2160) 螢幕，因此我盡可能使用 HiDPI 縮放，係數為 2。鋪設視窗管理器）和picom（康普頓作為合成器的精神繼承者），我通常必須親自動手來擴展Qt 應用程式。 Xfce 設定僅控制 GTK 應用程式。
要啟用 Qt 縮放，我通常遵循Arch 維基，添加export QT_SCALE_FACTOR=2我的.bashrc或嘗試替代方案（QT_AUTO_SCREEN_SCALE_FACTOR，QT_SCREEN_SCALE_FACTORS）直到它起作用。當我運行 Ubuntu 20.04 時它就完成了工作。
然而，由於我遷移到 Debian 11“Bullseye”，Qt 縮放現在在會話基礎上不一致。當它工作時，它對於每個應用程式都工作得很好。但其他時候，它根本不起作用。看來我必須重新啟動才能開始工作。這就像拋硬幣一樣，兩種結果出現的頻率都相對較高。
作為解決方法，我可以在啟動應用程式時在本地指定環境變量，而不是讓它在全域運行。例如，env QT_SCALE_FACTOR=2 qpdfview是否啟動具有適當縮放的 qpdfview。
這當然不方便，我寧願讓在 中定義的全域環境變數.bashrc發揮應有的作用。.bash_profile順便說一句，我也嘗試過創建替代方案，但它並沒有改善情況。
發生什麼事了？我懷疑啟動順序有問題。即使我沒有得到我的縮放比例，printenv也會顯示QT_SCALE_FACTOR（或任何替代方案）已列出......所以它就在那裡，但一定有什麼東西弄亂了它。我提到啟動順序是因為我的（誠然不尋常的）設定顯然對哪些進程已經（或沒有）正在運行很敏感；有時（雖然很少），我會啟動到一個混亂的面板和窗口，不能佔據超過螢幕的四分之一。所以我只是重新啟動就好了。
不管怎樣，我很感激你的幫助。先致謝！
編輯：問題解決了！ Lightdm 是肇事者。正如所解釋的這裡，.bashrc並且從 lightdm 登入時不會取得相關文件，因為顯示不是由 shell 啟動的。 Lightdm 確實解析了一些用於啟動腳本的文件，這是您可以儲存環境變數的地方。它們的確切名稱可能取決於發行版。 Archwiki 說~/.xprofile，但是在 Debian 上你會用~/.xsessionrc.
所以，我創建了~/.xsessionrc包含export QT_SCALE_FACTOR=2，現在它可以工作了。