根据Eric Postpischil的评论进行更正：
这是C标准允许的。C标准支持所有字母数字和29个附加字符。
C标准（C99 - C17）第6.10.2节第5段规定：
该实现应提供由一个或多个非数字或数字（6.4.2.1）后跟句点（.）和单个非数字组成的序列的唯一Map。第一个字符不应是数字。该实现可忽略字母大小写的区别，并将Map限制为句点前的八个有效字符。
编译器可能“允许”用前导数字构建程序，但这种行为可能无法在系统之间移植，因此不应使用。
请注意，此规则与标准（C99和C17）第6.4.7节第4段相矛盾，后者提供了以下示例：

#include <1/a.h>

头文件名可以以数字开头吗？
它可以以数字开头;C语法允许它。但是，C标准没有定义该行为，如下所述。（标题名称允许的字符序列在C 2018 6.4.7 1中定义，规则允许源字符集的任何成员，但换行符和>除外。）
是否存在这样做会造成危险的情况？
是的，C标准中的标题规则不要求名称以数字开头。C 2018 6.10.2 5规定“第一个字符不应是数字。”如果违反了此规则，则根据C 2018 4 2，C标准不定义该行为。
它还指出“实现应该为包含一个或多个非数字或数字的序列提供唯一Map（6.4.2.1）后接句点（.）和一个非数字”。您的名称也不符合这种模式，因为01_HeaderA.hpp在句点后面有三个字符。这并不表示C标准未定义的行为，但这确实意味着它们不必Map到文件系统中的唯一名称。
该段还指出“实现可能忽略字母大小写的区别，并将Map限制为句点之前的八个有效字符。”
大多数现代C实现将源代码中的头文件名直接Map到文件系统中的名称，必要时可能会忽略大小写。在某些情况下，它们可能会将尾随的.h转换为头文件托管库中的其他内容。不支持文件系统中的前导数字主要是旧操作系统的问题，因此今天您不太可能遇到这种情况。然而，因为C标准没有定义行为，所以你不能指望它是完全可移植的。
C标准有类似的措辞（在C 2020草案N4849，15.3 [cpp.include] 5中）。

头文件可以具有操作/文件系统支持的任何名称
是否存在这样做会造成危险的情况？
理论上是的，如果你试图在不支持以数字开头的文件名的操作系统托管的机器上编译你的程序。我不知道有这样的操作系统，但也许存在这样的操作系统