无缓冲的通道（unbuffered channel）是指在接收前没有能力保存任何值的通道。

这种类型的通道要求发送goroutine和接收goroutine同时准备好，才能完成发送和接收操作。否则，通道会导致先执行发送或接收操作的 goroutine 阻塞等待。

这种对通道进行发送和接收的交互行为本身就是同步的。其中任意一个操作都无法离开另一个操作单独存在。

阻塞：由于某种原因数据没有到达，当前协程（线程）持续处于等待状态，直到条件满足，才接触阻塞。

同步：在两个或多个协程（线程）间，保持数据内容一致性的机制。

下图展示两个 goroutine 如何利用无缓冲的通道来共享一个值：

在第 1 步，两个 goroutine 都到达通道，但哪个都没有开始执行发送或者接收。

在第 2 步，左侧的 goroutine 将它的手伸进了通道，这模拟了向通道发送数据的行为。这时，这个 goroutine 会在通道中被锁住，直到交换完成。

在第 3 步，右侧的 goroutine 将它的手放入通道，这模拟了从通道里接收数据。这个 goroutine 一样也会在通道中被锁住，直到交换完成。

在第 4 步和第 5 步，进行交换，并最终，在第 6 步，两个 goroutine 都将它们的手从通道里拿出来，这模拟了被锁住的 goroutine 得到释放。两个 goroutine 现在都可以去做别的事情了。

如果没有指定缓冲区容量，那么该通道就是同步的，因此会阻塞到发送者准备好发送和接收者准备好接收。

无缓冲channel： —— 同步通信

端口是给信息通讯所划分的通道口是相对于软件来说的，而接口是硬件连接的接口

有过一些黑客攻击方面知识的读者都会知道，其实那些所谓的黑客并不是像人们想象那样从天而降，而是实实在在从您的计算机"大门"中自由出入。计算机的"大门"就是我们平常所说的"端口"，它包括计算机的物理端口，如计算机的串口、并口、输入/输出设备以及适配器接口等（这些端口都是可见的），但更多的是不可见的软件端口，在本文中所介绍的都是指"软件端口"，但为了说明方便，仍统称为"端口"。本文仅就端口的基础知识进行介绍，

一、端口简介

随着计算机网络技术的发展，原来物理上的接口（如键盘、鼠标、网卡、显示卡等输入/输出接口）已不能满足网络通信的要求，TCP/IP协议作为网络通信的标准协议就解决了这个通信难题。TCP/IP协议集成到操作系统的内核中，这就相当于在操作系统中引入了一种新的输入/输出接口技术，因为在TCP/IP协议中引入了一种称之为"Socket（套接字）"应用程序接口。有了这样一种接口技术，一台计算机就可以通过软件的方式与任何一台具有Socket接口的计算机进行通信。端口在计算机编程上也就是"Socket接口"。

有了这些端口后，这些端口又是如何工作呢？例如一台服务器为什么可以同时是Web服务器，也可以是FTP服务器，还可以是邮件服务器等等呢？其中一个很重要的原因是各种服务采用不同的端口分别提供不同的服务，比如：通常TCP/IP协议规定Web采用80号端口，FTP采用21号端口等，而邮件服务器是采用25号端口。这样，通过不同端口，计算机就可以与外界进行互不干扰的通信。

据专家们分析，服务器端口数最大可以有65535个，但是实际上常用的端口才几十个，由此可以看出未定义的端口相当多。这是那么多黑客程序都可以采用某种方法，定义出一个特殊的端口来达到入侵的目的的原因所在。为了定义出这个端口，就要依靠某种程序在计算机启动之前自动加载到内存，强行控制计算机打开那个特殊的端口。这个程序就是"后门"程序，这些后门程序就是常说的木马程序。简单的说，这些木马程序在入侵前是先通过某种手段在一台个人计算机中植入一个程序，打开某个（些）特定的端口，俗称"后门"（BackDoor），使这台计算机变成一台开放性极高（用户拥有极高权限）的FTP服务器，然后从后门就可以达到侵入的目的。

二、端口的分类

端口的分类根据其参考对象不同有不同划分方法，如果从端口的性质来分，通常可以分为以下三类：

（1）公认端口（Well Known

Ports）：这类端口也常称之为"常用端口"。这类端口的端口号从0到1024，它们紧密绑定于一些特定的服务。通常这些端口的通信明确表明了某种服务的协议，这种端口是不可再重新定义它的作用对象。例如：80端口实际上总是HTTP通信所使用的，而23号端口则是Telnet服务专用的。这些端口通常不会像木马这样的黑客程序利用。为了使大家对这些常用端口多一些认识，在本章后面将详细把这些端口所对嬗Φ姆�窠�辛斜恚�└魑焕斫夂筒慰肌?

（2） 注册端口（Registered

Ports）：端口号从1025到49151。它们松散地绑定于一些服务。也是说有许多服务绑定于这些端口，这些端口同样用于许多其他目的。这些端口多数没有明确的定义服务对象，不同程序可根据实际需要自己定义，如后面要介绍的远程控制软件和木马程序中都会有这些端口的定义的。记住这些常见的程序端口在木马程序的防护和查杀上是非常有必要的。常见木马所使用的端口在后面将有详细的列表。

（3） 动态和/或私有端口（Dynamic and/or Private

Ports）：端口号从49152到65535。理论上，不应把常用服务分配在这些端口上。实际上，有些较为特殊的程序，特别是一些木马程序就非常喜欢用这些端口，因为这些端口常常不被引起注意，容易隐蔽。

如果根据所提供的服务方式的不同，端口又可分为"TCP协议端口"和"UDP协议端口"两种。因为计算机之间相互通信一般采用这两种通信协议。前面所介绍的"连接方式"是一种直接与接收方进行的连接，发送信息以后，可以确认信息是否到达，这种方式大多采用TCP协议；另一种是不是直接与接收方进行连接，只管把信息放在网上发出去，而不管信息是否到达，也就是前面所介绍的"无连接方式"。这种方式大多采用UDP协议，IP协议也是一种无连接方式。对应使用以上这两种通信协议的服务所提供的端口，也就分为"TCP协议端口"和"UDP协议端口"。

使用TCP协议的常见端口主要有以下几种：

（1） FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。

（2）

Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。

（3）

SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。

（4）

POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Foxmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮箱来收信）。

使用UDP协议端口常见的有：

（1）

HTTP：这是大家用得最多的协议，它就是常说的"超文本传输协议"。上网浏览网页时，就得在提供网页资源的计算机上打开80号端口以提供服务。常说"WWW服务"、"Web服务器"用的就是这个端口。

（2） DNS：用于域名解析服务，这种服务在Windows

NT系统中用得最多的。因特网上的每一台计算机都有一个网络地址与之对应，这个地址是常说的IP地址，它以纯数字+"."的形式表示。然而这却不便记忆，于是出现了域名，访问计算机的时候只需要知道域名，域名和IP地址之间的变换由DNS服务器来完成。DNS用的是53号端口。

（3） SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

（4）

OICQ：OICQ程序既接受服务，又提供服务，这样两个聊天的人才是平等的。OICQ用的是无连接的协议，也是说它用的是UDP协议。OICQ服务器是使用8000号端口，侦听是否有信息到来，客户端使用4000号端口，向外发送信息。如果上述两个端口正在使用（有很多人同时和几个好友聊天），就顺序往上加。

在计算机的6万多个端口，通常把端口号为1024以内的称之为常用端口，这些常用端口所对应的服务通常情况下是固定的。表1所列的都是服务器默认的端口，不允许改变，一般通信过程都主要用到这些端口。

表1

服务类型默认端口服务类型默认端口

Echo7Daytime13

FTP21Telnet23

SMTP25Time37

Whois43DNS53

Gopher70Finger79

WWW80POP3110

NNTP119IRC194

另外代理服务器常用以下端口：

（1）. HTTP协议代理服务器常用端口号：80/8080/3128/8081/9080

（2）. SOCKS代理协议服务器常用端口号：1080

（3）. FTP协议代理服务器常用端口号：21

（4）. Telnet协议代理服务器常用端口：23

三、端口在黑客中的应用

像木马之类的黑客程序，就是通过对端口的入侵来实现其目的的。在端口的利用上，黑客程序通常有两种方式，那就是"端口侦听"和"端口扫描"。

"端口侦听"与"端口扫描"是黑客攻击和防护中经常要用到的两种端口技术，在黑客攻击中利用它们可以准确地寻找攻击的目标，获取有用信息，在个人及网络防护方面通过这种端口技术的应用可以及时发现黑客的攻击及一些安全漏洞。下面首先简单介绍一下这两种端口技术的异同。

"端口侦听"是利用某种程序对目标计算机的端口进行监视，查看目标计算机上有哪能些端口是空闲、可以利用的。通过侦听还可以捕获别人有用的信息，这主要是用在黑客软件中，但对于个人来说也是非常有用的，可以用侦听程序来保护自己的计算机，在自己计算机的选定端口进行监视，这样可以发现并拦截一些黑客的攻击。也可以侦听别人计算机的指定端口，看是否空闲，以便入侵。

"端口扫描"（port

scanning）是通过连接到目标系统的TCP协议或UDP协议端口，来确定什么服务正在运行，然后获取相应的用户信息。现在有许多人把"端口侦听"与"端口扫描"混为一谈，根本分不清什么样的情况下要用侦听技术，什么样的情况下要用扫描技术。不过，现在的这类软件也似乎对这两种技术有点模糊了，有的干脆把两个功能都集成在一块。

"端口侦听"与"端口扫描"有相似之处，也有区别的地方，相似的地方是都可以对目标计算机进行监视，区别的地方是"端口侦听"属于一种被动的过程，等待别人的连接的出现，通过对方的连接才能侦听到需要的信息。在个人应用中，如果在设置了当侦听到有异常连接立即向用户报告这个功能时，就可以有效地侦听黑客的连接企图，及时把驻留在本机上的木马程序清除掉。这个侦听程序一般是安装在目标计算机上。用在黑客中的"端口侦听"通常是黑客程序驻留在服务器端等待服务器端在进行正常活动时捕获黑客需要的信息，然后通过UDP协议无连接方式发出去。而"端口扫描"则是一种主动过程，它是主动对目标计算机的选定端口进行扫描，实时地发现所选定端口的所有活动（特别是对一些网上活动）。扫描程序一般是安装在客户端，但是它与服务器端的连接也主要是通过无连接方式的UDP协议连接进行。

在网络中，当信息进行传播的时候，可以利用工具，将网络接口设置在侦听的模式，便可将网络中正在传播的信息截获或者捕获到，从而进行攻击。端口侦听在网络中的任何一个位置模式下都可实施进行，而黑客一般都是利用端口侦听来截取用户口令。

四、端口侦听原理

以太网（Ethernet）协议的工作方式是将要发送的数据包发往连接在一起的所有计算机。在包头中包括有应该接收数据包的计算机的正确地址，因为只有与数据包中目标地址一致的那台计算机才能接收到信息包。但是当计算机工作在侦听模式下，不管数据包中的目标物理地址是什么，计算机都将可以接收到。当同一网络中的两台计算机通信的时候，源计算机将写有目的计算机地址的数据包直接发向目的计算机，或者当网络中的一台计算机同外界的计算机通信时，源计算机将写有目的计算机IP地址的数据包发向网关。但这种数据包并不能在协议栈的高层直接发送出去，要发送的数据包必须从TCP/IP协议的IP协议层交给网络接口--数据链路层。网络接口不会识别IP地址的，在网络接口中，由IP协议层来的带有IP地址的数据包又增加了一部分以太网的帧头信息。在帧头中，有两个域分别为只有网络接口才能识别的源计算机和目的计算机的物理地址，这是一个48位的地址，这个48位的地址是与IP地址相对应的。换句话说，一个IP地址也会对应一个物理地址。对于作为网关的计算机，由于它连接了多个网络，它也就同时具备有很多个IP地址，在每个网络中它都有一个。而发向网络外的帧中继携带的是网关的物理地址。

以太网中填写了物理地址的帧从网络端口中（或者从网关端口中）发送出去，传送到物理的线路上。如果局域网是由一条粗同轴电缆或细同轴电缆连接成的，那么数字信号在电缆上传输信号就能够到达线路上的每一台计算机。再当使用集线器的时候，发送出去的信号到达集线器，由集线器再发向连接在集线器上的每一条线路。这样在物理线路上传输的数字信号也就能到达连接在集线器上的每个计算机了。当数字信号到达一台计算机的网络接口时，正常状态下网络接口对读入数据帧进行检查，如数据帧中携带的物理地址是自己的或者物理地址是广播地址，那么就会将数据帧交给IP协议层软件。对于每个到达网络接口的数据帧都要进行这个过程的。但是当计算机工作在侦听模式下，所有的数据帧都将被交给上层协议软件处理。

当连接在同一条电缆或集线器上的计算机被逻辑地分为几个子网的时候，那么要是有一台计算机处于侦听模式，它可以接收到发向与自己不在同一个子网（使用了不同的掩码、IP地址和网关）的计算机的数据包，在同一个物理信道上传输的所有信息都可以被接收到。

在UNIX系统上，当拥有超级权限的用户要想使自己所控制的计算机进入侦听模式，只需要向Interface（网络接口）发送I/O控制命令，就可以使计算机设置成侦听模式了。而在Windows

9x的系统中则不论用户是否有权限都将可以通过直接运行侦听工具就可以实现。

在端口处于侦听时，常常要保存大量的信息（也包含很多的垃圾信息），并将对收集的信息进行大量的整理，这样就会使正在侦听的计算机对其他用户的请求响应变的很慢。同时侦听程序在运行的时候需要消耗大量的处理器时间，如果在这时就详细的分析包中的内容，许多包就会来不及接收而被漏走。所以侦听程序很多时候就会将侦听得到的包存放在文件中等待以后分析。分析侦听到的数据包是很头疼的事情，因为网络中的数据包都非常之复杂。两台计算机之间连续发送和接收数据包，在侦听到的结果中必然会加一些别的计算机交互的数据包。侦听程序将同一TCP协议会话的包整理到一起就相当不容易，如果还期望将用户详细信息整理出来就需要根据协议对包进行大量的分析。

现在网络中所使用的协议都是较早前设计的，许多协议的实现都是基于一种非常友好的，通信的双方充分信任的基础。在通常的网络环境之下，用户的信息包括口令都是以明文的方式在网上传输的，因此进行端口侦听从而获得用户信息并不是一件难点事情，只要掌握有初步的TCP/IP协议知识就可以轻松的侦听到想要的信息的。

五、端口扫描原理

"端口扫描"通常指用同一信息对目标计算机的所有所需扫描的端口进行发送，然后根据返回端口状态来分析目标计算机的端口是否打开、是否可用。"端口扫描"行为的一个重要特征是：在短时期内有很多来自相同的信源地址传向不同的目的地端口的包。

对于用端口扫描进行攻击的人来说，攻击者总是可以做到在获得扫描结果的同时，使自己很难被发现或者说很难被逆向跟踪。为了隐藏攻击，攻击者可以慢慢地进行扫描。除非目标系统通常闲着（这样对一个没有listen端口的数据包都会引起管理员的注意），有很大时间间隔的端口扫描是很难被识别的。隐藏源地址的方法是发送大量的欺骗性的端口扫描包（1000个），其中只有一个是从真正的源地址来的。这样，即使全部包（1000）都被察觉，被记录下来，也没有人知道哪个是真正的信源地址。能发现的仅仅是"曾经被扫描过"。也正因为这样那些黑客们才乐此不彼地继续大量使用这种端口扫描技术来达到他们获取目标计算机信息、并进行恶意攻击。

通常进行端口扫描的工具目前主要采用的是端口扫描软件，也通称之为"端口扫描器"，端口扫描可以为提供三个用途：

（1）识别目标系统上正在运行的TCP协议和UDP协议服务。

（2）识别目标系统的操作系统类型（Windows 9x, Windows NT，或UNIX，等）。

（3）识别某个应用程序或某个特定服务的版本号。

端口扫描器是一种自动检测远程或本地计算机安全性弱点的程序，通过使用扫描器你可不留痕迹的发现远程服务器的各种TCP协议端口的分配及提供的服务，还可以得知它们所使用的软件版本！这就能让间接的了解到远程计算机所存在的安全问题。

端口扫描器通过选用远程TCP/IP协议不同的端口的服务，记录目标计算机端口给予的回答的方法，可以搜集到很多关于目标计算机的各种有用信息（比如：是否有端口在侦听？是否允许匿名登陆？是否有可写的FTP目录，是否能用TELNET等。

端口扫描器并不是一个直接攻击网络漏洞的程序，它仅仅能帮助发现目标机的某些内在的弱点。一个好的扫描器还能对它得到的数据进行分析，帮助查找目标计算机的漏洞。但它不会提供一个系统的详细步骤。

端口扫描器在扫描过程中主要具有以下三个方面的能力：

（1） 发现一个计算机或网络的能力；

（2） 一旦发现一台计算机，就有发现目标计算机正在运行什么服务的能力；

（3） 通过测试目标计算机上的这些服务，发现存在的漏洞的能力。

编写扫描器程序必须要很多TCP/IP协议程序编写和C，Perl和或SHELL语言的知识。需要一些Socket编程的背景，一种在开发客户/服务应用程序的方法。

六、常用端口

在计算机的6万多个端口，通常把端口号为1024以内的称之为常用端口，这些常用端口所对应的服务通常情况下是固定的，所以了解这些常用端口在一定程序上是非常必要的，下表2列出了计算机的常用端口所对应的服务（注：在这列表中各项"="前面的数字为端口号，"="后面的为相应端口服务。）。

1=tcpmux（TCP协议 Port Service Multiplexer）401=ups（Uninterruptible Power

Supply）

2=compressnet=Management Utility402=genie（Genie Protocol）

3=compressnet=Compression Process403=decap

5=rje（Remote Job Entry）404=nced

7=echo=Echo405=ncld

9=discard406=imsp（Interactive Mail Support Protocol）

11=systat,Active Users407=timbuktu

13=daytime408=prm-sm（Prospero Resource Manager Sys. Man.）

17=qotd（Quote of the Day）409=prm-nm（Prospero Resource Manager Node Man.）

18=msp（Message Send Protocol）410=decladebug（DECLadebug Remote Debug

Protocol）

19=Character Generator411=rmt（Remote MT Protocol）

20=FTP-data（File Transfer [Default Data]）412=synoptics-trap（Trap

Convention Port）

21=FTP（File Transfer [Control]）413=smsp

22=ssh414=infoseek

23=telnet415=bnet

24private mail system416=silverplatter

25=smtp（Simple Mail Transfer）417=onmux

27=nsw-fe（NSW User System FE）418=hyper-g

29=msg-icp419=ariel1

31=msg-auth420=smpte

33=Display Support Protocol421=ariel2

35=private printer server422=ariel3

37=time423=opc-job-start（IBM Operations Planning and Control Start）

38=rap（Route Access Protocol）424=opc-job-track（IBM Operations Planning and

Control Track）

39=rlp（Resource Location Protocol）425=icad-el（ICAD）

41=graphics426=smartsdp

42=nameserver（WINS Host Name Server）427=svrloc（Server Location）

43=nicname（Who Is）428=ocs_cmu

44=mpm-flags（MPM FLAGS Protocol）429=ocs_amu

45=mpm（Message Processing Module [recv]）430=utmpsd

46=mpm-snd（MPM [default send]）431=utmpcd

47=ni-ftp432=iasd

48=Digital Audit Daemon433=nnsp

49=tacacs（Login Host Protocol （TACACS））434=mobileip-agent

50=re-mail-ck（Remote Mail Checking Protocol）435=mobilip-mn

51=la-maint（IMP Logical Address Maintenance）436=dna-cml

52=xns-time（XNS Time Protocol）437=comscm

53=Domain Name Server438=dsfgw

54=xns-ch（XNS Clearinghouse）439=dasp（dasp Thomas Obermair）

55=isi-gl（ISI Graphics Language）440=sgcp

56=xns-auth（XNS Authentication）441=decvms-sysmgt

57= private terminal access442=cvc_hostd

58=xns-mail（XNS Mail）443=https（https Mcom）

59=private file service444=snpp（Simple Network Paging Protocol）

61=ni-mail（NI MAIL）445=microsoft-ds

62=acas（ACA Services）446=ddm-rdb

63=whois+whois+447=ddm-dfm

64=covia（Communications Integrator （CI））448=ddm-byte

65=tacacs-ds（TACACS-Database Service）449=as-servermap

66=sql*net（Oracle SQL*NET）450=tserver

67=bootps（Bootstrap Protocol Server）451=sfs-smp-net（Cray Network Semaphore

server）

68=bootpc（Bootstrap Protocol Client）452=sfs-config（Cray SFS config server）

69=tftp（Trivial File Transfer）453=creativeserver

70=gopher454=contentserver

71=netrjs-1,Remote Job Service455=creativepartnr

72=netrjs-2,Remote Job Service456=macon-tcp

73=netrjs-3,Remote Job Service457=scohelp

74=netrjs-4,Remote Job Service458=appleqtc（apple quick time）

75=private dial out service459=ampr-rcmd

76=deos（Distributed External Object Store）460=skronk

77=private RJE service461=datasurfsrv

78=vettcp462=datasurfsrvsec

79=finger463=alpes

80=http（World Wide Web HTTP）464=kpasswd

81=hosts2-ns（HOSTS2 Name Server）465=ssmtp

82=xfer（XFER Utility）466=digital-vrc

83=mit-ml-dev（MIT ML Device）467=mylex-mapd

84=ctf（Common Trace Facility）468=photuris

85=mit-ml-dev（MIT ML Device）469=rcp（Radio Control Protocol）

86=mfcobol（Micro Focus Cobol）470=scx-proxy

87= private terminal link471=mondex

88=kerberos472=ljk-login

89=su-mit-tg（SU/MIT Telnet Gateway）473=hybrid-pop

90=dnsix（DNSIX Securit Attribute Token Map）474=tn-tl-w1

91=mit-dov（MIT Dover Spooler）475=tcpnethaspsrv

92=npp（Network Printing Protocol）476=tn-tl-fd1

93=dcp（Device Control Protocol）477=ss7ns

94=objcall（Tivoli Object Dispatcher）478=spsc

95=supdup479=iafserver

96=dixie（DIXIE Protocol Specification）480=iafdbase

97=swift-rvf（Swift Remote Virtural File Protocol）481=ph（Ph service）

98=tacnews482=bgs-nsi

99=metagram,Metagram Relay483=ulpnet

100=newacct,[unauthorized use]484=integra-sme（Integra Software Management

Environment）

101=hostname,NIC Host Name Server485=powerburst（Air Soft Power Burst）

102=iso-tsap（ISO-TSAP Class 0）486=avian

103=gppitnp（Genesis Point-to-Point Trans Net）487=saft

104=acr-nema（ACR-NEMA Digital Imag. &Comm. 300）488=gss-http

105=Mailbox Name Nameserver489=nest-protocol

106=3com-tsmux（3COM-TSMUX）490=micom-pfs

107=rtelnet（Remote Telnet Service）491=go-login

108=snagas（SNA Gateway Access Server）492=ticf-1（Transport Independent

Convergence for FNA）

109=pop2（Post Office Protocol - Version 2）493=ticf-2（Transport Independent

Convergence for FNA）

110=pop3（Post Office Protocol - Version 3）494=pov-ray

111=sunrpc（SUN Remote Procedure Call）495=intecourier

112=mcidas（McIDAS Data Transmission Protocol）496=pim-rp-disc

113=auth（Authentication Service）497=dantz

114=audionews（Audio News Multicast）498=siam

115=sftp（Simple File Transfer Protocol）499=iso-ill（ISO ILL Protocol）

116=ansanotify（ANSA REX Notify）500=isakmp

117=uucp-path（UUCP Path Service）501=stmf

118=sqlserv502=asa-appl-proto

119=nntp（Network News Transfer Protocol）503=intrinsa

120=cfdptkt504=citadel

121=erpc（Encore Expedited Remote Pro.Call）505=mailbox-lm

122=smakynet506=ohimsrv

123=ntp（Network Time Protocol）507=crs

124=ansatrader（ANSA REX Trader）508=xvttp

125=locus-map（Locus PC-Interface Net Map Ser）509=snare

126=unitary（Unisys Unitary Login）510=fcp（FirstClass Protocol）

127=locus-con（Locus PC-Interface Conn Server）511=mynet（mynet-as）

128=gss-xlicen（GSS X License Verification）512=exec（remote process

execution）

129=pwdgen（Password Generator Protocol）513=login（remote login a la telnet）

130=cisco-fna（cisco FNATIVE）514=shell,cmd

131=cisco-tna（cisco TNATIVE）515=printer,spooler

132=cisco-sys（cisco SYSMAINT）516=videotex

133=statsrv（Statistics Service）517=talk（like tenex link）

134=ingres-net（INGRES-NET Service）518=ntalk

135=epmap（DCE endpoint resolution）519=utime（unixtime）

136=profile（PROFILE Naming System）520=efs（extended file name server）

137=netbios-ns（NETBIOS Name Service）521=ripng

138=netbios-dgm（NETBIOS Datagram Service）522=ulp

139=netbios-ssn（NETBIOS Session Service）523=ibm-db2

140=emfis-data（EMFIS Data Service）524=ncp

141=emfis-cntl（

此篇文章流传甚广, 其实里面没啥干货， 而且里面很多观点是有问题的. 这个文章在 golang-china 很早就讨论过了.

最近因为 Rust 1.0 和 1.1 的发布, 导致这个文章又出来毒害读者.

所以写了这篇反驳文章, 指出其中的问题.

有好几次，当我想起来的时候，总是会问自己：我为什么要放弃Go语言？这个决定是正确的吗？是明智和理性的吗？其实我一直在认真思考这个问题。

开门见山地说，我当初放弃Go语言（golang），就是因为两个“不爽”：第一，对Go语言本身不爽；第二，对Go语言社区里的某些人不爽。毫无疑问，这是非常主观的结论。但是我有足够详实的客观的论据，用以支撑这个看似主观的结论。

文末附有本文更新日志。

确实是非常主观的结论, 因为里面有不少有问题的观点(用来忽悠Go小白还行).

第0节：我的Go语言经历

先说说我的经历吧，以避免被无缘无故地当作Go语言的低级黑。

2009年底，Go语言（golang）第一个公开版本发布，笼罩着“Google公司制造”的光环，吸引了许多慕名而来的尝鲜者，我（Liigo）也身居其中，笼统的看了一些Go语言的资料，学习了基础的教程，因对其语法中的分号和花括号不满，很快就遗忘掉了，没拿它当一回事。

在2009年Go刚发布时, 确实是因为“Google公司制造”的光环而吸引了(包括文章作者和诸多IT记者)很多低级的尝鲜者.

还好, 经过5年的发展, 这些纯粹因为光环来的投机者所剩已经不多了(Google趋势).

目前, 真正的Go用户早就将Go用于实际的生产了.

说到 其语法中的分号和花括号不满, 我想说这只是你的 个人主观感受, 还有很多人对Go的分号和花括号很满意,

包括水果公司的的 Swift 的语言设计者也很满意这种风格(Swift中的分号和花括号和Go基本相同).

如果只谈 个人主观感受, 我也可以说 Rust 的 fn 缩写也很蛋疼!

两年之后，2011年底，Go语言发布1.0的计划被提上日程，相关的报道又多起来，我再次关注它，重新评估之后决定深入参与Go语言。我订阅了其users、nuts、dev、commits等官方邮件组，坚持每天阅读其中的电子邮件，以及开发者提交的每一次源代码更新，给Go提交了许多改进意见，甚至包括修改Go语言编译器源代码直接参与开发任务。如此持续了数月时间。

这个到是事实, 在 golang-china 有不少吵架的帖子, 感兴趣的可以去挖下, 我就不展开说了.

到2012年初，Go 1.0发布，语言和标准库都已经基本定型，不可能再有大幅改进，我对Go语言未能在1.0定型之前更上一个台阶、实现自我突破，甚至带着诸多明显缺陷走向1.0，感到非常失望，因而逐渐疏远了它（所以Go 1.0之后的事情我很少关心）。后来看到即将发布的Go 1.1的Release Note，发现语言层面没有太大改变，只是在库和工具层面有所修补和改进，感到它尚在幼年就失去成长的动力，越发失望。外加Go语言社区里的某些人，其中也包括Google公司负责开发Go语言的某些人，其态度、言行，让我极度厌恶，促使我决绝地离弃Go语言。

真的不清楚楼主说的可以在 Go1.0 之前短时间内能实现的 重大改进和诸多明显缺陷 是什么.

如果是楼主说前面的 其语法中的分号和花括号不满 之类的重大改进, 我只能说这只是你的 个人主观感受 而已,

你的很多想法只能说服你自己, 没办法说服其他绝大部分人(不要以为像C++或Rust那样什么特性都有就NB了, 各种NB特性加到一起只能是 要你命3000, 而绝对不会是什么 银弹).

Go 1.1的Release Note，发现语言层面没有太大改变. 语言层没有改变是是因为 Go1 作出的向后兼容的承诺. 对于工业级的语言来说, Go1 这个只能是优点. 如果连语言层在每个版本都会出现诸多大幅改进, 那谁还敢用Go语言来做生产开发呢(我承认Rust的改动很大胆, 但也说明了Rust还处于比较幼稚和任性的阶段)?

说 Go语言社区里的某些人固执 的观点我是同意的. 但是这些 固执 的人是可以讲道理的, 但是他们对很多东西的要求很高(特别是关于Go的设计哲学部分).

只要你给的建议有依据(语言的设计哲学是另外一回事情), 他们绝对不会盲目的拒绝(只是讨论的周期会比较长).

关于楼主提交的给Go文件添加BOM的文章, 需要补充说明下.

在Go1.0发布的时候, Go语言的源文件(.go)明确要求必须是UTF8编码的, 而且是无BOM的UTF8编码的.

注意: 这个 无BOM的UTF8编码 的限制仅仅是 针对 Go语言的源文件(.go).

这个限制并不是说不允许用户处理带BOM的UTF8的txt文件!

我觉得对于写Go程序来说, 这个限制是没有任何问题的, 到目前为止, 我还从来没有使用过带BOM的.go文件.

不仅是因为带BOM的.go文件没有太多的意义, 而且有很多的缺陷.

BOM的原意是用来表示编码是大端还是小端的, 主要用于UTF16和UTF32. 对于 UTF8 来说, BOM 没有任何存在的意义(正是Go的2个作者发明了UTF8, 彻底解决了全球的编码问题).

但是, 在现实中, 因为MS的txt记事本, 对于中文环境会将txt(甚至是C/C++源文件)当作GBK编码(GBK是个烂编码),

为了区别到底是GBK还是UTF8, MS的记事本在前面加了BOM这个垃圾(被GBK占了茅坑), 这里的bom已经不是表示字节序本意了. 不知道有没有人用ms的记事本写网页, 然后生成一个带bom的utf8网页肯定很有意思.

这是MS的记事本的BUG: 它不支持生成无BOM的UTF8编码的文本文件!

这些是现实存在的带BOM的UTF8编码的文本文件, 但是它们肯定都不是Go语言源文件!

所以说, Go语言的源文件即使强制限制了无BOM的UTF8编码要求, 也是没有任何问题的(而且我还希望有这个限制).

虽然后来Go源文件接受带BOM的UTF8了, 但是运行 go fmt 之后, 还是会删除掉BOM的(因为BOM就是然并卵). 也就是说 带 BOM 的 Go 源文件是不符合 Go语言的编码风格的, go fmt 会强制删除 BOM 头.

前面说了BOM是MS带来的垃圾, 但是BOM的UTF8除了然并卵之外还有很多问题, 因为BOM在string的开头嵌入了垃圾,

导致正则表达式, string的链接运算等操作都被会被BOM这个垃圾所污染. 对于.go语言, 即使代码完全一样, 有BOM和无BOM会导致文件的MD5之类的校验码不同.

所以, 我觉得Go用户不用纠结BOM这个无关紧要的东西.

在上一个10年，我（Liigo）在我所属的公司里，深度参与了两个编程语言项目的开发。我想，对于如何判断某个编程语言的优劣，或者说至少对于如何判断某个编程语言是否适合于我自己，我应该还是有一点发言权的。

第1节：我为什么对Go语言不爽？

Go语言有很多让我不爽之处，这里列出我现在还能记起的其中一部分，排名基本上不分先后。读者们耐心地看完之后，还能淡定地说一句“我不在乎”吗？

1.1 不允许左花括号另起一行

关于对花括号的摆放，在C语言、C++、Java、C#等社区中，十余年来存在持续争议，从未形成一致意见。在我看来，这本来就是主观倾向很重的抉择，不违反原则不涉及是非的情况下，不应该搞一刀切，让程序员或团队自己选择就足够了。编程语言本身强行限制，把自己的喜好强加给别人，得不偿失。无论倾向于其中任意一种，必然得罪与其对立的一群人。虽然我现在已经习惯了把左花括号放在行尾，但一想到被禁止其他选择，就感到十分不爽。Go语言这这个问题上，没有做到“团结一切可以团结的力量”不说，还有意给自己树敌，太失败了。

我觉得Go最伟大的发明是 go fmt, 从此Go用户不会再有花括弧的位置这种无聊争论了(当然也少了不少灌水和上tiobe排名的机会).

是这优点, Swift 语言也使用和 Go 类似的风格(当然楼主也可能鄙视swift的作者).

1.2 编译器莫名其妙地给行尾加上分号

对Go语言本身而言，行尾的分号是可以省略的。但是在其编译器（gc）的实现中，为了方便编译器开发者，却在词法分析阶段强行添加了行尾的分号，反过来又影响到语言规范，对“怎样添加分号”做出特殊规定。这种变态做法前无古人。在左花括号被意外放到下一行行首的情况下，它自动在上一行行尾添加的分号，会导致莫名其妙的编译错误（Go 1.0之前），连它自己都解释不明白。如果实在处理不好分号，干脆不要省略分号得了；或者，Scala和JavaScript的编译器是开源的，跟它们学学怎么处理省略行尾分号可以吗？

又是楼主的 个人主观感受, 不过我很喜欢这个特性. Swift 语言也是类似.

1.3 极度强调编译速度，不惜放弃本应提供的功能

程序员是人不是神，编码过程中免不了因为大意或疏忽犯一些错。其中有一些，是大家集体性的很容易就中招的错误（Go语言里的例子我暂时想不起来，C++里的例子有“基类析构函数不是虚函数”）。这时候编译器应该站出来，多做一些检查、约束、核对性工作，尽量阻止常规错误的发生，尽量不让有潜在错误的代码编译通过，必要时给出一些警告或提示，让程序员留意。编译器不就是机器么，不就是应该多做脏活累活杂活、减少人的心智负担么？编译器多做一项检查，可能会避免数十万程序员今后多年内无数次犯同样的错误，节省的时间不计其数，这是功德无量的好事。但是Go编译器的作者们可不这么想，他们不愿意自己多花几个小时给编译器增加新功能，觉得那是亏本，反而减慢了编译速度。他们以影响编译速度为由，拒绝了很多对编译器改进的要求。典型的因噎废食。强调编译速度固然值得赞赏，但如果因此放弃应有的功能，我不赞成。

编译速度是很重要的, 如果编译速度够慢, 语言再好也不会有人使用的.

比如C/C++的增量编译/预编译头文件/并发编译都是为了提高编译速度.

Rust1.1 也号称 比 1.0 的编译时间减少了32% (注意: 不是运行速度).

当然, Go刚面世的时候, 编译速度是其中的一个设计目标.

不过我想楼主, 可能想说的是因为编译器自己添加分号而导致的编译错误的问题.

我觉得Go中 { 不能另起一行是语言特性, 如果修复这个就是引入了新的错误.

其他的我真想不起来还有哪些 调编译速度，不惜放弃本应提供的功能 (不要提泛型, 那是因为还没有好的设计).

1.4 错误处理机制太原始

在Go语言中处理错误的基本模式是：函数通常返回多个值，其中最后一个值是error类型，用于表示错误类型极其描述；调用者每次调用完一个函数，都需要检查这个error并进行相应的错误处理：if err != nil { /*这种代码写多了不想吐么*/ }。此模式跟C语言那种很原始的错误处理相比如出一辙，并无实质性改进。实际应用中很容易形成多层嵌套的if else语句，可以想一想这个编码场景：先判断文件是否存在，如果存在则打开文件，如果打开成功则读取文件，如果读取成功再写入一段数据，最后关闭文件，别忘了还要处理每一步骤中出现错误的情况，这代码写出来得有多变态、多丑陋？实践中普遍的做法是，判断操作出错后提前return，以避免多层花括号嵌套，但这么做的后果是，许多错误处理代码被放在前面突出的位置，常规的处理逻辑反而被掩埋到后面去了，代码可读性极差。而且，error对象的标准接口只能返回一个错误文本，有时候调用者为了区分不同的错误类型，甚至需要解析该文本。除此之外，你只能手工强制转换error类型到特定子类型（静态类型的优势没了）。至于panic - recover机制，致命的缺陷是不能跨越库的边界使用，注定是一个半成品，最多只能在自己的pkg里面玩一玩。Java的异常处理虽然也有自身的问题（比如Checked Exceptions），但总体上还是比Go的错误处理高明很多。

话说, 软件开发都发展了半个世纪, 还是无实质性改进. 不要以为弄一个异常的语法糖就是革命了.

我只能说错误和异常是2个不同的东西, 将所有错误当作异常那是SB行为.

正因为有异常这个所谓的银弹, 导致很多等着别人帮忙擦屁股的行为(注意 shit 函数抛出的绝对不会是一种类型的 shit, 而被其间接调用的各种 xxx_shit 也可能抛出各种类型的异常, 这就导致 catch 失控了):

int main() {

try {

shit()

} catch( /* 到底有几千种 shit ? */) {

...

}

}

Go的建议是 panic - recover 不跨越边界, 也就是要求正常的错误要由pkg的处理掉.

这是负责任的行为.

再说Go是面向并发的编程语言, 在海量的 goroutine 中使用 try/catch 是不是有一种不伦不类的感觉呢?

1.5 垃圾回收器（GC）不完善、有重大缺陷

在Go 1.0前夕，其垃圾回收器在32位环境下有内存泄漏，一直拖着不肯改进，这且不说。Go语言垃圾回收器真正致命的缺陷是，会导致整个进程不可预知的间歇性停顿。像某些大型后台服务程序，如游戏服务器、APP容器等，由于占用内存巨大，其内存对象数量极多，GC完成一次回收周期，可能需要数秒甚至更长时间，这段时间内，整个服务进程是阻塞的、停顿的，在外界看来就是服务中断、无响应，再牛逼的并发机制到了这里统统失效。垃圾回收器定期启动，每次启动就导致短暂的服务中断，这样下去，还有人敢用吗？这可是后台服务器进程，是Go语言的重点应用领域。以上现象可不是我假设出来的，而是事实存在的现实问题，受其严重困扰的也不是一家两家了（2013年底ECUG Con 2013，京东的刘奇提到了Go语言的GC、defer、标准库实现是性能杀手，最大的痛苦是GC；美团的沈锋也提到Go语言的GC导致后台服务间隔性停顿是最大的问题。更早的网络游戏仙侠道开发团队也曾受Go垃圾回收的沉重打击）。在实践中，你必须努力减少进程中的对象数量，以便把GC导致的间歇性停顿控制在可接受范围内。除此之外你别无选择（难道你还想自己更换GC算法、甚至砍掉GC？那还是Go语言吗？）。跳出圈外，我近期一直在思考，一定需要垃圾回收器吗？没有垃圾回收器就一定是历史的倒退吗？（可能会新写一篇博客文章专题探讨。）

这是说的是32位系统, 这绝对不是Go语言的重点应用领域!! 我可以说Go出生就是面向64位系统和多核心CPU环境设计的. (再说 Rust 目前好像还不支持 XP 吧, 这可不可以算是影响巨大?)

32位当时是有问题, 但是对实际生产影响并不大(请问楼主还是在用32位系统吗, 还只安装4GB的内存吗). 如果是8位单片机环境, 建议就不要用Go语言了, 直接C语言好了.

而且这个问题早就不存在了(大家可以去看Go的发布日志).

Go的出生也就5年时间, GC的完善和改进是一个持续的工作, 2015年8月将发布的 Go1.5将采用并行GC.

关于GC的被人诟病的地方是会导致卡顿, 但是我以为这个主要是因为GC的实现还不够完美而导致的.

如果是完美的并发和增量的GC, 那应该不会出现大的卡顿问题的.

当然, 如果非要实时性, 那用C好了(实时并不表示性能高, 只是响应时间可控).

对于Rust之类没有GC的语言来说, 想很方便的开发并发的后台程序那几乎是不可能的.

不要总是吹Rust能代替底层/中层/上层的开发, 我们要看有谁用Rust真的做了什么.

1.6 禁止未使用变量和多余import

Go编译器不允许存在被未被使用的变量和多余的import，如果存在，必然导致编译错误。但是现实情况是，在代码编写、重构、调试过程中，例如，临时性的注释掉一行代码，很容易就会导致同时出现未使用的变量和多余的import，直接编译错误了，你必须相应的把变量定义注释掉，再翻页回到文件首部把多余的import也注释掉，……等事情办完了，想把刚才注释的代码找回来，又要好几个麻烦的步骤。还有一个让人蛋疼的问题，编写数据库相关的代码时，如果你import某数据库驱动的pkg，它编译给你报错，说不需要import这个未被使用的pkg；但如果你听信编译器的话删掉该import，编译是通过了，运行时必然报错，说找不到数据库驱动；你看看程序员被折腾的两边不是人，最后不得不请出大神：import _。对待这种问题，一个比较好的解决方案是，视其为编译警告而非编译错误。但是Go语言开发者很固执，不容许这种折中方案。

这个问题我只能说楼主的吐槽真的是没水平.

为何不使用的是错误而不是警告? 这是为了将低级的bug消灭在编译阶段(大家可以想下C/C++的那么多警告有什么卵用).

而且, import 即使没有使用的话, 也是用副作用的, 因为 import 会导致 init 和全局变量的初始化.

如果某些代码没有使用, 为何要执行 init 这些初始化呢?

如果是因为调试而添加的变量, 那么调试完删除不是很正常的要求吗?

如果是因为调试而要导入fmt或log之类的包, 删除调试代码后又导致 import 错误的花,

楼主难道不知道在一个独立的文件包装下类似的辅助调试的函数吗?

import (

"fmt"

"log"

)

func logf(format string, a ...interface{}) {

file, line := callerFileLine()

fmt.Fprintf(os.Stderr, "%s:%d: ", file, line)

fmt.Fprintf(os.Stderr, format, a...)

}

func fatalf(format string, a ...interface{}) {

file, line := callerFileLine()

fmt.Fprintf(os.Stderr, "%s:%d: ", file, line)

fmt.Fprintf(os.Stderr, format, a...)

os.Exit(1)

}

import _ 是有明确行为的用法, 就是为了执行包中的 init 等函数(可以做某些注册操作).

将警告当作错误是Go的一个哲学, 当然在楼主看来这是白痴做法.

1.7 创建对象的方式太多令人纠结

创建对象的方式，调用new函数、调用make函数、调用New方法、使用花括号语法直接初始化结构体，你选哪一种？不好选择，因为没有一个固定的模式。从实践中看，如果要创建一个语言内置类型（如channel、map）的对象，通常用make函数创建；如果要创建标准库或第三方库定义的类型的对象，首先要去文档里找一下有没有New方法，如果有就最好调用New方法创建对象，如果没有New方法，则退而求其次，用初始化结构体的方式创建其对象。这个过程颇为周折，不像C++、Java、C#那样直接new就行了。

C++的new是狗屎. new导致的问题是构造函数和普通函数的行为不一致, 这个补丁特性真的没啥优越的.

我还是喜欢C语言的 fopen 和 malloc 之类构造函数, 构造函数就是普通函数, Go语言中也是这样.

C++中, 除了构造不兼容普通函数, 析构函数也是不兼容普通函数. 这个而引入的坑有很多吧.

1.8 对象没有构造函数和析构函数

没有构造函数还好说，毕竟还有自定义的New方法，大致也算是构造函数了。没有析构函数就比较难受了，没法实现RAII。额外的人工处理资源清理工作，无疑加重了程序员的心智负担。没人性啊，还嫌我们程序员加班还少吗？C++里有析构函数，Java里虽然没有析构函数但是有人家finally语句啊，Go呢，什么都没有。没错，你有个defer，可是那个defer问题更大，详见下文吧。

defer 可以覆盖析构函数的行为, 当然 defer 还有其他的任务. Swift2.0 也引入了一个简化版的 defer 特性.

1.9 defer语句的语义设定不甚合理

Go语言设计defer语句的出发点是好的，把释放资源的“代码”放在靠近创建资源的地方，但把释放资源的“动作”推迟（defer）到函数返回前执行。遗憾的是其执行时机的设置似乎有些不甚合理。设想有一个需要长期运行的函数，其中有无限循环语句，在循环体内不断的创建资源（或分配内存），并用defer语句确保释放。由于函数一直运行没有返回，所有defer语句都得不到执行，循环过程中创建的大量短暂性资源一直积累着，得不到回收。而且，系统为了存储defer列表还要额外占用资源，也是持续增加的。这样下去，过不了多久，整个系统就要因为资源耗尽而崩溃。像这类长期运行的函数，http.ListenAndServe()就是典型的例子。在Go语言重点应用领域，可以说几乎每一个后台服务程序都必然有这么一类函数，往往还都是程序的核心部分。如果程序员不小心在这些函数中使用了defer语句，可以说后患无穷。如果语言设计者把defer的语义设定为在所属代码块结束时（而非函数返回时）执行，是不是更好一点呢？可是Go 1.0早已发布定型，为了保持向后兼容性，已经不可能改变了。小心使用defer语句！一不小心就中招。

前面说到 defer 还有其他的任务, 也就是 defer 中执行的 recover 可以捕获 panic 抛出的异常.

还有 defer 可以在 return 之后修改命名的返回值.

上面2个工作要求 defer 只能在函数退出时来执行.

楼主说的 defer 是类似 Swift2.0 中 defer 的行为, 但是 Swift2.0 中 defer 是没有前面2个特性的.

Go中的defer是以函数作用域作为触发的条件的, 是会导致楼主说的在 for 中执行的错误用法(哪个语言没有坑呢?).

不过 for 中 局部 defer 也是有办法的 (Go中的defer是以函数作用域):

for {

func(){

f, err := os.Open(...)

defer f.Close()

}()

}

在 for 中做一个闭包函数就可以了. 自己不会用不要怪别人没告诉你.

1.10 许多语言内置设施不支持用户定义的类型

for in、make、range、channel、map等都仅支持语言内置类型，不支持用户定义的类型(?)。用户定义的类型没法支持for in循环，用户不能编写像make、range那样“参数类型和个数”甚至“返回值类型和个数”都可变的函数，不能编写像channel、map那样类似泛型的数据类型。语言内置的那些东西，处处充斥着斧凿的痕迹。这体现了语言设计的局限性、封闭性、不完善，可扩展性差，像是新手作品——且不论其设计者和实现者如何权威。延伸阅读：Go语言是30年前的陈旧设计思想，用户定义的东西几乎都是二等公民（Tikhon Jelvis）。

说到底, 这个是因为对泛型支持的不完备导致的.

Go语言是没啥NB的特性, 但是Go的特性和工具组合在一起就是好用.

这就是Go语言NB的地方.

1.11 没有泛型支持，常见数据类型接口丑陋

没有泛型的话，List、Set、Tree这些常见的基础性数据类型的接口就只能很丑陋：放进去的对象是一个具体的类型，取出来之后成了无类型的interface{}（可以视为所有类型的基础类型），还得强制类型转换之后才能继续使用，令人无语。Go语言缺少min、max这类函数，求数值绝对值的函数abs只接收/返回双精度小数类型，排序接口只能借助sort.Interface无奈的回避了被比较对象的类型，等等等等，都是没有泛型导致的结果。没有泛型，接口很难优雅起来。Go开发者没有明确拒绝泛型，只是说还没有找到很好的方法实现泛型（能不能学学已经开源的语言呀）。现实是，Go 1.0已经定型，泛型还没有，那些丑陋的接口为了保持向后兼容必须长期存在着。

Go有自己的哲学, 如果能有和目前哲学不冲突的泛型实现, 他们是不会反对的.

如果只是简单学学(或者叫抄袭)已经开源的语言的语法, 那是C++的设计风格(或者说C++从来都是这样设计的, 有什么特性就抄什么), 导致了各种脑裂的编程风格.

编译时泛型和运行时泛型可能是无法完全兼容的, 看这个例子:

type Adder<T>interface {

Add(a, b T) T

}

---