我遇到了其中一个不一致发生的问题，因此即使对我来说也很难复制。
我有一个 4K (3840x2160) 屏幕，因此我尽可能使用 HiDPI 缩放，系数为 2。但是，由于我正在运行将 Xfce（用于面板、设置和会话管理器）与 bspwm 相结合的自定义设置（平铺窗口管理器）和 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，现在它可以工作了。