为什么无法用“\\localhost”访问本机的共享？
其实碰到这个问题已经很久了──在运行对话框里输入“\\localhost”并回车，Windows 2000/XP居然会提示网络重名，并且居然建议我们更改计算机名，如下图所示。相反如果输入“127.0.0.1”并回车，则可以顺利访问本机的共享文件夹。
提示 对于Windows NT，则会出现找不到网络路径的错误信息。
工作组环境网络访问需要受到多种因素的制约。从TCP/IP协议层次的角度来看，从下到上依次是物理底层（网线网卡等）、网络协议|服务|端口、用户身份验证、安全策略、和共享资源的权限等。
从故障现象来看，可以进行名字解析，此时尚未进行用户身份验证（安全策略和资源权限无从谈起），所以问题应该与“网络协议|服务|端口”等因素有关。只是“网络重名”这个故障现象着实“妖异”得紧……
通过查阅KB254210，总算知道了原因，由于该KB写得相对比较粗略，所以这里我特地撰写本帖，以作为该KB的补充读物：
大家知道，从Windows 2000开始，Windows同时采用以下两套相对独立的机制，来支持Microsoft文件和打印机服务，如下图所示。
（1）传统的NetBT（NetBIOS over TCP/IP），走137/UDP、138/UDP和139/TCP端口。
（2）TCP/IP上的SMB直接承载（Direct Hosting of SMB Over TCP/IP），走445/TCP端口。
也就是说“Microsoft文件和打印机服务”现在同时支持Windows Sockets和NetBIOS API。在默认情况下，Windows会同时尝试这两种机制。客户机和文件服务器建立新连接的时候，两套机制进行公平竞争，谁先做出响应就使用谁。
那么\\localhost应该走哪一条路呢？先做一个实验帮助理解：
（1）打开命令提示符窗口，运行以下命令：
net config workstation
（2）命令结果将类似下图所示。
图中的“NetBT_Tcpip_{C5665A07-7119-4A2B-B970-02C01FD663C8} (000C29C1E329)”表明，NetBT绑定到具体的物理网卡（但是不包括Loopback接口），其中的{C5665A07-7119-4A2B-B970-02C01FD663C8}表示该网卡的GUID，(000C29C1E329)则是该网卡的MAC地址。
图中的“NetbiosSmb (000000000000)”则表明，“SMB直接承载”绑定到所有网络接口（ADDR_ANY），也包括Loopback接口。
从这个实验可以得知，\\localhost只能走第二条路“SMB直接承载”，而不能走NetBT，这就是为什么在NT上会出现找不到网络路径的原因（NT不支持“SMB直接承载”）。
\\localhost走“SMB直接承载”的大致过程是这样的：
（1）将localhost解析为127.0.0.1。
（2）顺利建立TCP连接。
（3）系统会验证目标计算机（就是本机）的计算机名是否为“localhost”，而本机的计算机名并不是“localhost”，所以验证失败，系统会认为在网络中存在一台重名计算机而报错。
这就是\\localhost为什么会失败的原理，原因在于系统会验证目标计算机的计算机名。我们还可以“构造”以下的案例来证实这个验证机制：
（1）假设文件服务器的计算机名为Test，IP地址是192.168.0.1。
（2）在客户机的hosts文件里添加一条错误的名字解析记录“192.168.0.1 NoTest”。
（3）在客户机的“运行”对话框里输入\\NoTest并回车，虽然NoTest被解析为192.168.0.1，客户机能够和Test计算机建立连接，但是系统接下来会发现目标计算机的计算机并不是“NoTest”，而是“Test”，所以会报错──错误信息正是我们所预料的──“由于网络上有重名，没有连接”。
参考资料
有以下参考资料可以供您参考：
（1）微软知识库文章KB254210：这是本帖的主要参考资料，其URL为：
http://support.microsoft.com/kb/254210
（2）Windows 2000 Server Resource Kit：
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/cnet/cnbc_imp_wcug.asp
（3）我的webcast《工作组环境里的网络访问疑难解答》
http://www.microsoft.com/china/technet/webcasts/ondemand/episode.aspx?newsID=msft032205vx