区别在于被破坏的标识符的名称(_ZN12_GLOBAL__N_11bE vs _ZL1b，这并不重要，但它们都被组装为符号表中的局部符号(缺少.global asm指令)。

#include<iostream>
namespace {
   int a = 3;
}

static int b = 4;
int c = 5;

int main (){
    std::cout << a << b << c;
}

        .data
        .align 4
        .type   _ZN12_GLOBAL__N_11aE, @object
        .size   _ZN12_GLOBAL__N_11aE, 4
_ZN12_GLOBAL__N_11aE:
        .long   3
        .align 4
        .type   _ZL1b, @object
        .size   _ZL1b, 4
_ZL1b:
        .long   4
        .globl  c
        .align 4
        .type   c, @object
        .size   c, 4
c:
        .long   5
        .text

对于嵌套的匿名命名空间:

namespace {
   namespace {
       int a = 3;
    }
}

        .data
        .align 4
        .type   _ZN12_GLOBAL__N_112_GLOBAL__N_11aE, @object
        .size   _ZN12_GLOBAL__N_112_GLOBAL__N_11aE, 4
_ZN12_GLOBAL__N_112_GLOBAL__N_11aE:
        .long   3

翻译单元中所有第一级匿名命名空间相互组合，翻译单元中所有第二级嵌套匿名命名空间相互组合

还可以在匿名名称空间中拥有嵌套名称空间或嵌套内联名称空间

namespace {
   namespace A {
       int a = 3;
    }
}

        .data
        .align 4
        .type   _ZN12_GLOBAL__N_11A1aE, @object
        .size   _ZN12_GLOBAL__N_11A1aE, 4
_ZN12_GLOBAL__N_11A1aE:
        .long   3

which for the record demangles as:
        .data
        .align 4
        .type   (anonymous namespace)::A::a, @object
        .size   (anonymous namespace)::A::a, 4
(anonymous namespace)::A::a:
        .long   3

//inline has the same output

您还可以使用匿名的内联名称空间，但据我所知，匿名名称空间上的内联效果为0

inline namespace {
   inline namespace {
       int a = 3;
    }
}

_ZL1b: _Z表示这是一个错误的标识符。L表示它是通过静态的局部符号。1是标识符b的长度，然后是标识符b

_ZN12_GLOBAL__N_11aE _Z表示这是一个错误的标识符。N表示这是一个命名空间12是匿名命名空间名称_GLOBAL__N_1的长度，然后是匿名命名空间名称_GLOBAL__N_1，然后1是标识符a的长度，a是标识符a, E关闭命名空间中的标识符。

_ZN12_GLOBAL__N_11A1aE与上面相同，除了其中有另一个命名空间(1A)称为A，前缀为A的长度为1。匿名命名空间的名称都是_GLOBAL__N_1

将方法放在匿名名称空间中可以防止您意外地违反One Definition Rule，允许您不必担心将您的helper方法命名为与您可能链接的其他方法相同的方法。

而且，正如luke所指出的，标准更喜欢匿名名称空间而不是静态成员。

根据我的经验，我只想指出，虽然这是c++将以前的静态函数放入匿名名称空间的方式，但旧的编译器有时会在这方面遇到问题。我目前正在使用一些用于目标平台的编译器，更现代的Linux编译器可以很好地将函数放置到匿名名称空间中。

但是在Solaris上运行的旧编译器有时会接受它，有时会将其标记为错误，直到未来未指定的版本发布。我担心的不是这个错误，而是它在接受错误时可能会做什么。因此，在全面现代化之前，我们仍然使用静态(通常是类作用域)函数，我们更喜欢匿名名称空间。

我最近开始在代码中用匿名名称空间替换静态关键字，但很快就遇到了一个问题，即名称空间中的变量在调试器中不再可用。我使用的是VC60，所以我不知道其他调试器是否没有问题。我的解决方法是定义一个“模块”命名空间，在那里我给它我的cpp文件的名字。

例如，在我的xmlutil_cpp文件中，我定义了一个名称空间XmlUtil_I{…}用于我的所有模块变量和函数。这样我就可以在调试器中应用XmlUtil_I::资格来访问变量。在本例中，_I将其与公共名称空间区分开来，例如我可能希望在其他地方使用的XmlUtil。

我认为，与真正的匿名方法相比，这种方法的潜在缺点是，有人可能会在其他模块中使用名称空间限定符，从而违反所需的静态作用域。我不知道这是否是一个主要的问题。

就我个人而言，我更喜欢静态函数而不是无名称的名称空间，原因如下:

It's obvious and clear from function definition alone that it's private to the translation unit where it's compiled. With nameless namespace you might need to scroll and search to see if a function is in a namespace. Functions in namespaces might be treated as extern by some (older) compilers. In VS2017 they are still extern. For this reason even if a function is in nameless namespace you might still want to mark them static. Static functions behave very similar in C or C++, while nameless namespaces are obviously C++ only. nameless namespaces also add extra level in indentation and I don't like that :)

所以，我很高兴看到静态函数不再被弃用了。

此外，如果在变量上使用static关键字，例如:

namespace {
   static int flag;
}

在映射文件中不会看到它