重庆分公司
重庆分公司，新征程启航
为企业提供网站建设、域名注册、服务器等服务
关于go语言txt写入的信息
go语言怎么判断一个结构体里有几个字段
feof()，用这个函数判断是否读到文件尾了。fread(buf,size,count,fp);//buf输入数据起始地址，size每个数据块的大小，count每次写入的数据块个数，fp文件指针写好后是：while(!feof(fp)){fread(temp[i],sizeof(structuse),1,fp);//这个读出来放数组里面i++;}问题是你读的是txt文件，完全可以用fscanf()函数么。
成都创新互联公司是一家专业提供新华企业网站建设,专注与成都网站建设、网站建设、H5开发、小程序制作等业务。10年已为新华众多企业、政府机构等服务。创新互联专业的建站公司优惠进行中。
驳狗屎文 "我为什么放弃Go语言
此篇文章流传甚广, 其实里面没啥干货， 而且里面很多观点是有问题的. 这个文章在 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 AdderT interface {
Add(a, b T) T
}
如何配置go语言开发环境
1.1 Go 安装
Go的三种安装方式
Go有多种安装方式，你可以选择自己喜欢的。这里我们介绍三种最常见的安装方式：
Go源码安装：这是一种标准的软件安装方式。对于经常使用Unix类系统的用户，尤其对于开发者来说，从源码安装可以自己定制。
Go标准包安装：Go提供了方便的安装包，支持Windows、Linux、Mac等系统。这种方式适合快速安装，可根据自己的系统位数下载好相应的安装包，一路next就可以轻松安装了。**推荐这种方式**
第三方工具安装：目前有很多方便的第三方软件包工具，例如Ubuntu的apt-get、Mac的homebrew等。这种安装方式适合那些熟悉相应系统的用户。
最后，如果你想在同一个系统中安装多个版本的Go，你可以参考第三方工具GVM，这是目前在这方面做得最好的工具，除非你知道怎么处理。
Go源码安装
在Go的源代码中，有些部分是用Plan 9 C和ATT汇编写的，因此假如你要想从源码安装，就必须安装C的编译工具。
在Mac系统中，只要你安装了Xcode，就已经包含了相应的编译工具。
在类Unix系统中，需要安装gcc等工具。例如Ubuntu系统可通过在终端中执行sudo apt-get install gcc
libc6-dev来安装编译工具。
在Windows系统中，你需要安装MinGW，然后通过MinGW安装gcc，并设置相应的环境变量。
你可以直接去官网下载源码，找相应的goVERSION.src.tar.gz的文件下载，下载之后解压缩到$HOME目录，执行如下代码：
cd go/src
./all.bash
运行all.bash后出现"ALL TESTS PASSED"字样时才算安装成功。
上面是Unix风格的命令，Windows下的安装方式类似，只不过是运行all.bat，调用的编译器是MinGW的gcc。
如果是Mac或者Unix用户需要设置几个环境变量，如果想重启之后也能生效的话把下面的命令写到.bashrc或者.zshrc里面，
export GOPATH=$HOME/gopath
export PATH=$PATH:$HOME/go/bin:$GOPATH/bin
如果你是写入文件的，记得执行bash .bashrc或者bash
.zshrc使得设置立马生效。
如果是window系统，就需要设置环境变量，在path里面增加相应的go所在的目录，设置gopath变量。
当你设置完毕之后在命令行里面输入go，看到如下图片即说明你已经安装成功
图1.1 源码安装之后执行Go命令的图
如果出现Go的Usage信息，那么说明Go已经安装成功了；如果出现该命令不存在，那么可以检查一下自己的PATH环境变中是否包含了Go的安装目录。
关于上面的GOPATH将在下面小节详细讲解
Go标准包安装
Go提供了每个平台打好包的一键安装，这些包默认会安装到如下目录：/usr/local/go
(Windows系统：c:\Go)，当然你可以改变他们的安装位置，但是改变之后你必须在你的环境变量中设置如下信息：
export GOROOT=$HOME/go
export GOPATH=$HOME/gopath
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
上面这些命令对于Mac和Unix用户来说最好是写入.bashrc或者.zshrc文件，对于windows用户来说当然是写入环境变量。
如何判断自己的操作系统是32位还是64位？
我们接下来的Go安装需要判断操作系统的位数，所以这小节我们先确定自己的系统类型。
Windows系统用户请按Win+R运行cmd，输入systeminfo后回车，稍等片刻，会出现一些系统信息。在“系统类型”一行中，若显示“x64-based
PC”，即为64位系统；若显示“X86-based PC”，则为32位系统。
Mac系统用户建议直接使用64位的，因为Go所支持的Mac OS X版本已经不支持纯32位处理器了。
Linux系统用户可通过在Terminal中执行命令arch(即uname
-m)来查看系统信息：
64位系统显示
x86_64
32位系统显示
i386
Mac 安装
访问下载地址，32位系统下载go1.4.2.darwin-386-osx10.8.pkg，64位系统下载go1.4.2.darwin-amd64-osx10.8.pkg，双击下载文件，一路默认安装点击下一步，这个时候go已经安装到你的系统中，默认已经在PATH中增加了相应的~/go/bin,这个时候打开终端，输入go
看到类似上面源码安装成功的图片说明已经安装成功
如果出现go的Usage信息，那么说明go已经安装成功了；如果出现该命令不存在，那么可以检查一下自己的PATH环境变中是否包含了go的安装目录。
Linux 安装
访问下载地址，32位系统下载go1.4.2.linux-386.tar.gz，64位系统下载go1.4.2.linux-amd64.tar.gz，
假定你想要安装Go的目录为 $GO_INSTALL_DIR，后面替换为相应的目录路径。
解压缩tar.gz包到安装目录下：tar zxvf go1.4.2.linux-amd64.tar.gz -C
$GO_INSTALL_DIR。
设置PATH，export PATH=$PATH:$GO_INSTALL_DIR/go/bin
然后执行go
图1.2 Linux系统下安装成功之后执行go显示的信息
如果出现go的Usage信息，那么说明go已经安装成功了；如果出现该命令不存在，那么可以检查一下自己的PATH环境变中是否包含了go的安装目录。
Windows 安装
访问Google Code 下载页，32
位请选择名称中包含 windows-386 的 msi 安装包，64 位请选择名称中包含 windows-amd64 的。下载好后运行，不要修改默认安装目录
C:\Go\，若安装到其他位置会导致不能执行自己所编写的 Go 代码。安装完成后默认会在环境变量 Path 后添加 Go 安装目录下的 bin 目录
C:\Go\bin\，并添加环境变量 GOROOT，值为 Go 安装根目录 C:\Go\ 。
验证是否安装成功
在运行中输入 cmd 打开命令行工具，在提示符下输入 go，检查是否能看到 Usage 信息。输入
cd %GOROOT%，看是否能进入 Go 安装目录。若都成功，说明安装成功。
不能的话请检查上述环境变量 Path 和 GOROOT 的值。若不存在请卸载后重新安装，存在请重启计算机后重试以上步骤。
第三方工具安装
GVM
gvm是第三方开发的Go多版本管理工具，类似ruby里面的rvm工具。使用起来相当的方便，安装gvm使用如下命令：
bash (curl -s -S -L )
安装完成后我们就可以安装go了：
gvm install go1.4.2
gvm use go1.4.2
也可以使用下面的命令，省去每次调用gvm use的麻烦： gvm use go1.4.2 --default
执行完上面的命令之后GOPATH、GOROOT等环境变量会自动设置好，这样就可以直接使用了。
apt-get
Ubuntu是目前使用最多的Linux桌面系统，使用apt-get命令来管理软件包，我们可以通过下面的命令来安装Go，为了以后方便，应该把
git mercurial 也安装上：
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:gophers/go
sudo apt-get update
sudo apt-get install golang-stable git-core mercurial
homebrew
homebrew是Mac系统下面目前使用最多的管理软件的工具，目前已支持Go，可以通过命令直接安装Go，为了以后方便，应该把
git mercurial 也安装上：
brew update brew upgrade
brew install go
brew install git
brew install mercurial
go语言 file.WriteString(str + "\n")，不能写入“\n”换行符，结果只一行，怎么输出换行的文件？
换行符 \n 在 Windows 记事本不会显示，用 Notepad2、Notepad++、UltraEdit 等打开就能看到，或者用 \r\n
php和go语言哪个好
前言
最近工作中遇到的一个场景，php项目中需要使用一个第三方的功能，而恰好有一个用Golang写好的类库。那么问题就来了，要如何实现不同语言之间的通信呢？下面就来一起看看吧。
常规的方案
1、 用Golang写一个http/TCP服务，php通过http/TCP与Golang通信
2、将Golang经过较多封装，做为php扩展。
3、PHP通过系统命令，调取Golang的可执行文件
存在的问题
1、http请求，网络I/O将会消耗大量时间
2、需要封装大量代码
3、PHP每调取一次Golang程序，就需要一次初始化，时间消耗很多
优化目标
1、Golang程序只初始化一次（因为初始化很耗时）
2、所有请求不需要走网络
3、尽量不大量修改代码
解决方案
1、简单的Golang封装，将第三方类库编译生成为一个可执行文件
2、PHP与Golang通过双向管道通信
使用双向管道通信优势
1：只需要对原有Golang类库进行很少的封装
2：性能最佳 （IPC通信是进程间通信的最佳途径）
3：不需要走网络请求，节约大量时间
4：程序只需初始化一次，并一直保持在内存中
具体实现步骤
1：类库中的原始调取demo
package main
import (
"fmt"
"github.com/yanyiwu/gojieba"
"strings"
)
func main() {
x := gojieba.NewJieba()
defer x.Free()
s := "小明硕士毕业于中国科学院计算所，后在日本京都大学深造"
words := x.CutForSearch(s, true)
fmt.Println(strings.Join(words, "/"))
}
保存文件为main.go，就可以运行
2：调整后代码为：
package main
import (
"bufio"
"fmt"
"github.com/yanyiwu/gojieba"
"io"
"os"
"strings"
)
func main() {
x := gojieba.NewJieba(
"/data/tmp/jiebaDict/jieba.dict.utf8",
"/data/tmp/jiebaDict/hmm_model.utf8",
"/data/tmp/jiebaDict/user.dict.utf8"
)
defer x.Free()
inputReader := bufio.NewReader(os.Stdin)
for {
s, err := inputReader.ReadString('\n')
if err != nil err == io.EOF {
break
}
s = strings.TrimSpace(s)
if s != "" {
words := x.CutForSearch(s, true)
fmt.Println(strings.Join(words, " "))
} else {
fmt.Println("get empty \n")
}
}
}
只需要简单的几行调整，即可实现：从标准输入接收字符串，经过分词再输出
测试：
# go build test
# ./test
# //等待用户输入，输入”这是一个测试“
# 这是 一个 测试 //程序
3：使用cat与Golang通信做简单测试
//准备一个title.txt，每行是一句文本
# cat title.txt | ./test
正常输出，表示cat已经可以和Golang正常交互了
4：PHP与Golang通信
以上所示的cat与Golang通信，使用的是单向管道。即：只能从cat向Golang传入数据，Golang输出的数据并没有传回给cat，而是直接输出到屏幕。但文中的需求是：php与Golang通信。即php要传数据给Golang，同时Golang也必须把执行结果返回给php。因此，需要引入双向管道。
在PHP中管道的使用：popen("/path/test") ，具体就不展开说了，因为此方法解决不了文中的问题。
双向管道：
$descriptorspec = array(
0 = array("pipe", "r"),
1 = array("pipe", "w")
);
$handle = proc_open(
'/webroot/go/src/test/test',
$descriptorspec,
$pipes
);
fwrite($pipes['0'], "这是一个测试文本\n");
echo fgets($pipes[1]);
解释：使用proc_open打开一个进程，调用Golang程序。同时返回一个双向管道pipes数组，php向$pipe['0']中写数据，从$pipe['1']中读数据。
好吧，也许你已经发现，我是标题档，这里重点要讲的并不只是PHP与Golang如何通信。而是在介绍一种方法： 通过双向管道让任意语言通信。（所有语言都会实现管道相关内容）
测试：
通过对比测试，计算出各个流程占用的时间。下面提到的title.txt文件，包含100万行文本，每行文本是从b2b平台取的商品标题
1: 整体流程耗时
time cat title.txt | ./test /dev/null
耗时：14.819秒，消耗时间包含：
进程cat读出文本
通过管道将数据传入Golang
Golang处理数据，将结果返回到屏幕
2：计算分词函数耗时。方案：去除分词函数的调取，即：注释掉Golang源代码中的调取分词那行的代码
time cat title.txt | ./test /dev/null
耗时：1.817秒时间，消耗时间包含：
进程cat读出文本
通过管道将数据传入Golang
Golang处理数据，将结果返回到屏幕
分词耗时 = (第一步耗时) - (以上命令所耗时)
分词耗时 : 14.819 - 1.817 = 13.002秒
3：测试cat进程与Golang进程之间通信所占时间
time cat title.txt /dev/null
耗时：0.015秒，消耗时间包含：
进程cat读出文本
通过管道将数据传入Golang
go处理数据，将结果返回到屏幕
管道通信耗时：（第二步耗时） - （第三步耗时）
管道通信耗时： 1.817 - 0.015 = 1.802秒
4：PHP与Golang通信的时间消耗
编写简单的php文件：
?php
$descriptorspec = array(
0 = array("pipe", "r"),
1 = array("pipe", "w")
);
$handle = proc_open(
'/webroot/go/src/test/test',
$descriptorspec,
$pipes
);
$fp = fopen("title.txt", "rb");
while (!feof($fp)) {
fwrite($pipes['0'], trim(fgets($fp))."\n");
echo fgets($pipes[1]);
}
fclose($pipes['0']);
fclose($pipes['1']);
proc_close($handle);
流程与上面基本一致，读出title.txt内容，通过双向管道传入Golang进程分词后，再返回给php （比上面的测试多一步：数据再通过管道返回）
time php popen.php /dev/null
耗时：24.037秒，消耗时间包含：
进程PHP读出文本
通过管道将数据传入Golang
Golang处理数据
Golang将返回结果再写入管道，PHP通过管道接收数据
将结果返回到屏幕
结论：
1 ：整个分词过程中的耗时分布
使用cat控制逻辑耗时： 14.819 秒
使用PHP控制逻辑耗时: 24.037 秒（比cat多一次管道通信）
单向管道通信耗时： 1.8 秒
Golang中的分词函数耗时： 13.002 秒
2：分词函数的性能： 单进程，100万商品标题分词，耗时13秒
以上时间只包括分词时间，不包括词典载入时间。但在本方案中，词典只载入一次，所以载入词典时间可以忽略（1秒左右）
3：PHP比cat慢 (这结论有点多余了，呵呵）
语言层面慢: (24.037 - 1.8 - 14.819) / 14.819 = 50%
单进程对比测试的话，应该不会有哪个语言比cat更快。
相关问题：
1：以上Golang源码中写的是一个循环，也就是会一直从管道中读数据。那么存在一个问题：是不是php进程结束后，Golang的进程还会一直存在？
管道机制自身可解决此问题。管道提供两个接口：读、写。当写进程结束或者意外挂掉时，读进程也会报错，以上Golang源代码中的err逻辑就会执行，Golang进程结束。
但如果PHP进程没有结束，只是暂时没有数据传入，此时Golang进程会一直等待。直到php结束后，Golang进程才会自动结束。
2：能否多个php进程并行读写同一个管道，Golang进程同时为其服务？
不可以。管道是单向的，如果多个进程同时向管道中写，那Golang的返回值就会错乱。
可以多开几个Golang进程实现，每个php进程对应一个Golang进程。
最后，上面都是瞎扯的。如果你了解管道、双向管道，上面的解释对你基本没啥用。但如果你不了解管道，调试上面的代码没问题，但稍有修改就有可能掉坑里。
[原创] 深入剖析mmap原理 - 从三个关键问题说起
对于mmap，您是否能从原理上解析以下三个问题：
要解决这些疑问，可能还需要在操作系统层面多了解。本文将尝试通过这些问题深入剖析，希望通过这篇文章，能使大家对mmap有较深入的认识，也能在存储引擎的设计中，有所参考。
最近在研发分布式日志存储系统，这是一个基于Raft协议的自研分布式日志存储系统，Logstore则是底层存储引擎。
Logstore中，使用mmap对数据文件进行读写。Logstore的存储结构简化如下图：
Logstore使用了Segments Files + Index Files的方式存储Log，Segment File是存储主体，用于存储Log数据，使用定长的方式，默认每个512M，Index File主要用于Segment File的内容检索。
Logstore使用mmap的方式读写Segment File，Segments Files的个数，主要取决于磁盘空间或者业务需求，一般情况下，Logstore会存储1T~5T的数据。
我们先看看什么是mmap。
在深入理解计算机系统这本书中，mmap定义为：Linux通过将一个虚拟内存区域与一个磁盘上的对象(object)关联起来，以初始化这个虚拟内存区域的内容，这个过程称为内存映射(memory mapping)。
在Logstore中，mapping的对象是普通文件(Segment File)。
我们先来简单看一下mapping一个文件，mmap做了什么事情。如下图所示：
假设我们mmap的文件是FileA，在调用mmap之后，会在进程的虚拟内存分配地址空间，创建映射关系。
这里值得注意的是， mmap只是在虚拟内存分配了地址空间 ，举个例子，假设上述的FileA是2G大小
在mmap之后，查看mmap所在进程的maps描述，可以看到
由上可以看到，在mmap之后，进程的地址空间7f35eea8d000-7f366ea8d000被分配，并且map到FileA，7f366ea8d000减去7f35eea8d000，刚好是2147483648(ps: 这里是整个文件做mapping)
在Linux中，VM系统通过将虚拟内存分割为称作虚拟页(Virtual Page，VP)大小固定的块来处理磁盘(较低层)与上层数据的传输，一般情况下，每个页的大小默认是4096字节。同样的，物理内存也被分割为物理页(Physical Page，PP)，也为4096字节。
上述例子，在mmap之后，如下图：
在mmap之后，并没有在将文件内容加载到物理页上，只上在虚拟内存中分配了地址空间。当进程在访问这段地址时（通过mmap在写入或读取时FileA），若虚拟内存对应的page没有在物理内存中缓存，则产生"缺页"，由内核的缺页异常处理程序处理，将文件对应内容，以页为单位(4096)加载到物理内存，注意是只加载缺页，但也会受操作系统一些调度策略影响，加载的比所需的多，这里就不展开了。
(PS: 再具体一些，进程在访问7f35eea8d000这个进程虚拟地址时，MMU通过查找页表，发现对应内容未缓存在物理内存中，则产生"缺页")
缺页处理后，如下图：
我认为从原理上，mmap有两种类型，一种是有backend，一种是没有backend。
这种模式将普通文件做memory mapping(非MAP_ANONYMOUS)，所以在mmap系统调用时，需要传入文件的fd。这种模式常见的有两个常用的方式，MAP_SHARED与MAP_PRIVATE，但它们的行为却不相同。
1) MAP_SHARED
这个方式我认为可以从两个角度去看：
2) MAP_PRIVATE
这是一个copy-on-write的映射方式。虽然他也是有backend的，但在写入数据时，他会在物理内存copy一份数据出来(以页为单位)，而且这些数据是不会被回写到文件的。这里就要注意，因为更新的数据是一个副本，而且不会被回写，这就意味着如果程序运行时不主动释放，若更新的数据超过可用物理内存+swap space，就会遇到OOM Killer。
无backend通常是MAP_ANONYMOUS，就是将一个区域映射到一个匿名文件，匿名文件是由内核创建的。因为没有backend，写入/更新的数据之后，若不主动释放，这些占用的物理内存是不能被释放的，同样会出现OOM Killer。
到这里，这个问题就比较好解析了。我们可以将此问题分离为：
-- 虚拟内存是否会出问题：
回到上述的"mmap在进程虚拟内存做了什么"，我们知道mmap会在进程的虚拟内存中分配地址空间，比如1G的文件，则分配1G的连续地址空间。那究竟可以maping多少呢？在64位操作系统，寻址范围是2^64 ，除去一些内核、进程数据等地址段之外，基本上可以认为可以mapping无限大的数据(不太严谨的说法)。
-- 物理内存是否会出问题
回到上述"mmap的分类"，对于有backend的mmap，而且是能回写到文件的，映射比内存+swap空间大是没有问题的。但无法回写到文件的，需要非常注意，主动释放。
MAP_NORESERVE是mmap的一个参数，MAN的说明是"Do not reserve swap space for this mapping. When swap space is reserved, one has the guarantee that it is possible to modify the mapping."。
我们做个测试：
场景A：物理内存+swap space: 16G，映射文件30G，使用一个进程进行mmap，成功后映射后持续写入数据
场景B：物理内存+swap space: 16G，映射文件15G，使用两个进程进行mmap，成功后映射后持续写入数据
从上述测试可以看出，从现象上看，NORESERVE是绕过mmap的校验，让其可以mmap成功。但其实在RESERVE的情况下(序列4)，从测试结果看，也没有保障。
mmap的性能经常与系统调用（write/read）做对比。
我们将读写分开看，先尝试从原理上分析两者的差异，然后再通过测试验证。
我们先来简单讲讲write系统调用写文件的过程：
再来简单讲讲使用mmap时，写入文件流程：
系统调用会对性能有影响，那么从理论上分析:
下面我们对两者进行性能测试：
场景：对2G的文件进行顺序写入(go语言编写)
每次写入大小 | mmap 耗时 | write 耗时
--------------- | ------- | -------- | --------
| 1 byte | 22.14s | 300s
| 100 bytes | 2.84s | 22.86s
| 512 bytes | 2.51s | 5.43s
| 1024 bytes | 2.48s | 3.48s
| 2048 bytes | 2.47s | 2.34s
| 4096 bytes | 2.48s | 1.74s
| 8192 bytes | 2.45s | 1.67s
| 10240 bytes | 2.49s | 1.65s
可以看到mmap在100byte写入时已经基本达到最大写入性能，而write调用需要在4096(也就是一个page size)时，才能达到最大写入性能。
从测试结果可以看出，在写小数据时，mmap会比write调用快，但在写大数据时，反而没那么快(但不太确认是否go的slice copy的性能问题，没时间去测C了)。
测试结果与理论推导吻合。
我们还是来简单分析read调用与mmap的流程：
从图中可以看出，read调用确实比mmap多一次copy。因为read调用，进程是无法直接访问kernel space的，所以在read系统调用返回前，内核需要将数据从内核复制到进程指定的buffer。但mmap之后，进程可以直接访问mmap的数据(page cache)。
从原理上看，read性能会比mmap慢。
接下来实测一下性能区别：
场景：对2G的文件进行顺序读取(go语言编写)
(ps: 为了避免磁盘对测试的影响，我让2G文件都缓存在pagecache中)
每次读取大小 | mmap 耗时 | write 耗时
--------------- | ------- | -------- | --------
| 1 byte | 8215.4ms | 300s
| 100 bytes | 86.4ms | 8100.9ms
| 512 bytes | 16.14ms | 1851.45ms
| 1024 bytes | 8.11ms | 992.71ms
| 2048 bytes | 4.09ms | 636.85ms
| 4096 bytes | 2.07ms | 558.10ms
| 8192 bytes | 1.06ms | 444.83ms
| 10240 bytes | 867.88µs | 475.28ms
由上可以看出，在read上面，mmap比write的性能差别还是很大的。测试结果与理论推导吻合。
对mmap的深入了解，能帮助我们在设计存储系统时，更好地进行决策。
比如，假设需要设计一个底层的数据结构是B+ Tree，node操作以Page单位的单机存储引擎，根据上述推论，写入使用系统调用，而读取使用mmap，可以达到最优的性能。而LMDB就是如此实现的。
文章名称：关于go语言txt写入的信息
分享路径：http://cqcxhl.com/article/hidsjc.html