你想去解决它第二段要解决的问题吧？我没在用户环境测试过，我的直觉是：sans-serif 是在 45 添加，于是一些无衬线体在 56-65 期间就 prepend 完了，然后你追加 monospace，针对它的规则也在 56-65 里，应该不会添加等宽体，添加的只是这个锚点。同样删掉的也只是 sans-serif 这个锚点，之前 prepend 的无衬线体不会随着锚点丢失而自动删除。这个问题在 user conf 里其实是没法解决的，原因就是顺序问题
@marguerite
我观察的实际情况是这段配置在 user conf 里面解决了顺序问题，sans-serif 这个锚点和它的 prepend 等规则随着锚点丢失一并被删除了，只留下了 monospace，我再看看 FC_DEBUG 的结果确认一下。
上游这个 fontconfig 确实太傻逼了，给它交了个 PR 试图挽救一下：
但是即便是这样，你也不应该这么做啊…同时有 sans-serif 和 monospace 就删 sans-serif，这个溢出效应很大啊
我觉得没毛病啊……一个字体如果同时是等宽和无衬线的话就按等宽处理我没意见……
当然我觉得不应该把这个配置打包进系统就是了
每个中文字不都是这样的嘛 
你这个配置我感觉如果你整个系统都没有中文等宽字体，那你的 konsole/gnome-terminal 这些应用里中文可能就是口口口了，因为 sans-serif 的规则没有应用。默认当作 sans-serif 这个 feature 还是挺有用的。Noto 系列就没等宽中文
@marguerite
实际上 fontconfig 不认为中文字是等宽字体，例如"fc-match -s “Noto Sans SC”"并不会得到等宽字体作为 fallback。我运行了"fc-query /usr/share/fonts/truetype/NotoSansSC-Regular.otf"也没有得到 spacing 这个 field。
你做反了吧，你匹配一个无衬线体肯定不是等宽的啊…但是你单独匹配 monospace 这个默认情况，要是一个等宽中文没有不得拿实际是等宽的无衬线体去 fallback 么，你这么一删全删没了…
我现在用的就是这个配置，Konsole 的字体设定为 Cascadia Code，中文可以正常显示。
那你肯定有等宽中文呗，文泉驿默认装的。或者就是我可能给 monospace 配了无衬线体中文当等宽。
@marguerite
现在我的效果是，虽然 Noto Sans SC 在列表后面了，但是还是存在的（即使我删除了 sans-serif），我的 monospace 字体设置是空的。当然实际采用的是 WenQuanYi Micro Hei Mono，不过这个字体没了也没关系因为后面还有 Noto Sans SC。
fc-match -s Hack 的结果在这里：
我没明白你为什么讨论任何问题都要 fc-match -s Hack…你 fc-match monospace 不行嘛？我说的是这种情况，konsole 你不去专门改成 Hack，它是 monospace 这个 alias…我 60-family-prefer 里设了文鼎上海宋，CMEXSong 和文泉驿这三个无衬线体当等宽的。把它们都移动走…
不行的。在上面的帖子里面写过了，因为我（自己觉得）“fc-match -s monospace”（或者其他虚拟锚点字体）的机制和过程我已经完全清楚并可以用配置文件控制了。现在我不明白的是"fc-match -s Hack"(或者其他实际字体) 的过程。