正如 Praetorian 在下面的评论中指出的那样，使用 devtoolset 实际上解决了我最初在这个答案中描述的问题。我已经更正了答案。
由于这些库的 4.4 和 4.7 版本之间存在一些不匹配，我的程序是否存在错误的风险？
是的。100% 不支持链接到较新的 libstdc++.so，然后尝试运行较旧的 libstdc++.so。如果程序中的任何对象或它使用的任何库都使用 GCC 4.7 编译并链接到 4.7 中的 libstdc++.so，那么您需要在运行时使用 4.7（或更高版本）中的 libstdc++.so。它甚至可能不会运行，但如果运行，可能会由于不兼容而出现无声错误。但这对您来说不是问题，因为您没有链接到 GCC 4.7 的 libstdc++.so，请参见下文。
我可以通过静态链接 GCC 4.7 的 libc 和 libstdc++ 版本来解决这个问题吗？
1）您只需要为 libstdc++ 执行此操作，因为没有“GCC 4.7 的 libc 版本”之类的东西。Glibc 是一个完全独立于 GCC 的项目。当您使用 GCC 4.7 时，您没有使用不同的 libc，您仍在使用 CentOS 6.4 中的系统 libc。（顺便说一句，请注意，glibc 维护人员强烈建议不要静态链接 glibc，并且 glibc 的某些功能在静态链接时将不起作用。）
2) 静态链接 libstdc++ 可以解决该问题，但您不需要这样做，因为无论如何Red Hat Developer Toolset (devtoolset) 就是为您做的。devtoolset 的全部意义在于它允许您使用更新的 GCC 和更新的 libstdc++，但不会在更新的 libstdc++ 库上创建任何运行时依赖项。编译的可执行文件只需要 libstdc++.so 的系统版本，它始终存在于 RHEL/CentOS 上，即使是没有安装 devtoolset 的系统。（devtoolset 所做的是将所有新的 libstdc++ 功能打包到一个静态库中，调用该库libstdc++_nonshared.a以使系统 libstdc++.so 中不存在的所有部分都静态链接，而其他所有内容都来自系统 libstdc++.so）。
如果您没有使用 devtoolset，那么另一种选择而不是静态链接 libstdc++ 将是与您的代码一起发布较新的 libstdc++.so 并确保首先找到它（例如，通过将您的代码与引用较新的 libstdc++.so 的 RPATH 链接）。但是使用 devtoolset 就没有必要了。
或者，如果/当我的代码动态加载的其他库选择系统范围的 GCC 4.4 包提供的较旧的 libc / libstdc++ 时，是否会为其他问题做好准备？
使用 devtoolset 时不会出现这样的问题，因为您总是使用较旧的 libstdc++，因此永远不会发生冲突。