We wanted the numbers to line up, so we set the whole line in a monospace font. The line also had Chinese in it.
The numbers lined up. The Chinese came out in a font we had never chosen.
Font fallback is silent
The browser takes a character and looks for it in the font you specified. If it isn’t there, it tries the next font in the list. If none of them has it, it uses the system default.
None of this raises a warning. No console message, no error, nothing in red. All you see is that the Chinese on this line looks a bit different from everywhere else.
And in the design file that line is usually just numbers, so nobody notices in review.
Two more traps nearby
① Listing a Chinese font after the monospace font doesn’t mean it falls back to that one. Fallback works character by character, but within a single font stack the Chinese characters can drop all the way to the system default instead of stopping at the font you had in mind, unless you name it explicitly. For any label that contains Chinese, we name the font directly and don’t rely on the stack.
② Popular free font services don’t always carry the Chinese version you want. Ask for it in the same request as the Latin version and the service quietly gives you only the one it has. The request succeeds, the status is 200, and half of it is missing.
What we do
Wrap only the numbers that need fixed widths, not the whole line.
To verify, don’t ask the font API whether the font has loaded. Its answer means “I tried,” not “it’s in use.” Draw it to a canvas once and compare pixels. The same character in two different fonts never produces the same pixels.
