当客户端在 发出POST请求时/albums，您希望将请求正文中描述的专辑添加到现有专辑数据中。
创新互联技术团队10余年来致力于为客户提供做网站、网站设计、成都品牌网站建设、成都营销网站建设、搜索引擎SEO优化等服务。经过多年发展，公司拥有经验丰富的技术团队，先后服务、推广了上千网站，包括各类中小企业、企事单位、高校等机构单位。
为此，您将编写以下内容：
1、编写代码
a.添加代码以将专辑数据添加到专辑列表。
在此代码中：
1）用于Context.BindJSON 将请求正文绑定到newAlbum。
2） album将从 JSON 初始化的结构附加到albums 切片。
3）向响应添加201状态代码，以及表示您添加的专辑的 JSON。
b.更改您的main函数，使其包含该router.POST函数，如下所示。
在此代码中：
1）将路径中的POST方法与 /albumspostAlbums函数相关联。
使用 Gin，您可以将处理程序与 HTTP 方法和路径组合相关联。这样，您可以根据客户端使用的方法将发送到单个路径的请求单独路由。
a.如果服务器从上一节开始仍在运行，请停止它。
b.从包含 main.go 的目录中的命令行，运行代码。
c.从不同的命令行窗口，用于curl向正在运行的 Web 服务发出请求。
该命令应显示添加专辑的标题和 JSON。
d.与上一节一样，使用curl检索完整的专辑列表，您可以使用它来确认添加了新专辑。
该命令应显示专辑列表。
当客户端向 发出请求时GET /albums/[id]，您希望返回 ID 与id路径参数匹配的专辑。
为此，您将：
a.在您在上一节中添加的函数下方postAlbums，粘贴以下代码以检索特定专辑。
此getAlbumByID函数将提取请求路径中的 ID，然后找到匹配的专辑。
在此代码中：
（1）Context.Param用于从 URL 中检索id路径参数。当您将此处理程序映射到路径时，您将在路径中包含参数的占位符。
（2）循环album切片中的结构，寻找其ID 字段值与id参数值匹配的结构。如果找到，则将该album结构序列化为 JSON，并将其作为带有200 OK HTTP 代码的响应返回。
如上所述，实际使用中的服务可能会使用数据库查询来执行此查找。
（3）如果找不到专辑，则返回 HTTP 404错误。
b.最后，更改您的main，使其包含对router.GET的新调用，路径现在为/albums/:id ，如以下示例所示。
在此代码中：
（1）将/albums/:id路径与getAlbumByID功能相关联。在 Gin 中，路径中项目前面的冒号表示该项目是路径参数。
a.如果服务器从上一节开始仍在运行，请停止它。
b.在包含 main.go 的目录中的命令行中，运行代码以启动服务器。
c.从不同的命令行窗口，用于curl向正在运行的 Web 服务发出请求。
该命令应显示您使用其 ID 的专辑的 JSON。如果找不到专辑，您将收到带有错误消息的 JSON。
恭喜！您刚刚使用 Go 和 Gin 编写了一个简单的 RESTful Web 服务。
本节包含您使用本教程构建的应用程序的代码。
1、值接收者和指针接收者
所谓指针接收者和值接收者这两个概念，用GO写了一阵子代码的人都了解了，这里只做简要说明一下，也就是对于一个给定结构，咱们对结构进行方法包装的时候，固定必传的参数，用来指向这个对象结构自身的一个参数，在go中也就是形式如下：
我们对结构体testStruct进行了包装，提供了两个方法，sum和modify，其中sum的方法接收者为a testStruct，这个就是值接收者，而modify的接收者为a *testStruct就是指针接收者，也就是说固定对象指针，一个传递的是指针地址，而另外一个直接传递的是结构值拷贝了
对指针有一定了解的，都可以知道，指针传递过去的，可以直接修改结构内部内容，而值传递过去的，无论如何修改这个接收者的数据，不会对原对象结构产生影响。而对于咱们包装结构对象的时候，到底是使用指针还是使用值接收者，这个实际上没有太大的定论，就我个人的观点来说，如果结构体占有的内存空间不大(kb级别)，而又不需要修改内部的，同时结构对象内部没有同步对象比如（sync包中的mutex,rwlock，waitgroup等之类的结构的话，可以直接值传递，实际上值copy也没有咱们想象的那么慢，很多时候，都用指针，最后的gc回收扫描可能都比咱们这个传递copy的消耗大） p="" /kb级别)，而又不需要修改内部的，同时结构对象内部没有同步对象比如（sync包中的mutex,rwlock，waitgroup等之类的结构的话，可以直接值传递，实际上值copy也没有咱们想象的那么慢，很多时候，都用指针，最后的gc回收扫描可能都比咱们这个传递copy的消耗大）
2、实现接口的值接收者和指针接收者有啥区别
也就是比如定义如下
这里面的值接收者和指针接收者有什么区别，这里咱来写一个测试
通过这个测试用例可以发现，指针接收者实现的接口可以同时支持转移到值接收者接口和指针接收者接口，而用值接收者实现的接口，则无法转移到使用指针接收者实现的接口，为啥子呢？目前网上或者各类资料上都是给的一个很官方很官方，而且很书面话难以理解的说明，大致意思如下：
这是目前网络或者各种资料上都是差不多是这样说的，看似讲了，实际上就说了一个结果，根本就没说出来一个为什么。这样的总结出来，一个初学者的角度来看，是很不好理解的，初学者要么就是死记硬背，要么就是生搬硬套，甚至直到写了好多好多代码了，都还没有搞明白一个为啥子，只是会用了而已，从长远来说这是不利于自身提高的。
有这两个本质点，咱们自己来思考一下，如果你来实现这个编译器的时候，用指针接收的时候，指针接收者，默认就能直接获取支持，而值接收者实现接口的咱们可以直接来一个解指针就变成了值，就能匹配上值接收者实现的接口了，反过来说，如果值接收者，此时要匹配指针接收者，如何匹配呢，取一个地址就变成了指针了，此时数据类型确实是匹配了，但是，地址指向的数据区不对了，因为我们刚刚说了值接收者拷贝了一个新值之后是完全的一个新的对象，这个新对象和原始对象一点关系都没有，咱们取地址，取的也是这个新对象地址，对这个地址进行操作，也是这个新对象的内部数据，和原始数据内部没有任何关系，所以由此就能推断出，这个是为啥子值接收者不能匹配上指针接收者，而指针接收者却可以匹配上值接收者了。
1、在某个作用域内部，所有定义的字符串的数据区相同
这个很好验证，代码如下：
2、字符串相加会产生一个新串
这个也很好验证
3、字符串真的是不可变的吗
实际上从字符串的结构
从这个结构，就能大致的推断出来，字符串设计成这样就不具备直接扩容+来增加新数据，而如果咱们直接使用string[index] = 'a'，用这种方式，就不能编译通过，官方也确定说字符串是不可变的。那么真的是不可变的吗？
通过上面的结构，在加上go的slice切片的数据结构
由此可见，咱们可以将字符串通过指针方式强转为一个byte数组指针，然后通过byte切片来修改，试试
编译通过，运行报错
unexpected fault address 0xae2e27
fatal error: fault
这个错误，基本上就是一个内存的保护错误，是写异常，所以说明了，这个肯定做了内存写保护，那么直接修改一下内存区的属性，去掉他的写保护，就能写了
以下代码都是在Win平台，Go1.18，Win上修改内存权限属性，使用VirtualProtect,代码如下
此时运行，就能发现tstr的内容被咱们变了，这种情况实际上在实际开发中不具有实际意义，因为本身在语言层面，已经做了层层限制，咱们这是属于非法强制的操作方式，是流氓行为，那么是否有比较温和一点的操作方式呢？答案是有的，且往下看。
通过上面，我们已经用到了字符串结构，切片结构，要想字符串内容可变，那么咱们自己构造字符串的数据内容区域，且让这个数据区木有内存写保护不就行了，内容区可变，GO原生态的byte数组不就行嘛，所以咱们自己构造一下
此时我们直接修改buffer的内容，就是直接修改了str的数据内容了。而又不会像前面的一样遇到内存写保护
4、字符串转换优化时可能碰到的坑
通过前面讨论的字符串的可变性的方法，咱们可以知道，很多时候，[]byte到字符串的转变，可以直接构造其结构，而共享数据，从而达到减少数据内存copy的方式来进行优化，再使用这些优化的时候，一定需要注意，字符串或者数组的生命周期，是否会存在被改写的情况，从而导致前后不一致的问题。
比如下面这段代码：
大家可以猜想一下，这个最后里面的数据mmp中，"test"的value是多少,"abcd"的value是多少，然后想想为什么，且等端午之后，再来分解
TiDB 是 PingCAP 自主研发的开源分布式关系型数据库，具备商业级数据库的数据可靠性，可用性，安全性等特性，支持在线弹性水平扩展，兼容 MySQL 协议及生态，创新性实现 OLTP 及 OLAP 融合。
TiDB 3.0 版本显著提升了大规模集群的稳定性，集群支持 150+ 存储节点，300+TB 存储容量长期稳定运行。易用性方面引入大量降低用户运维成本的优化，包括引入 Information_Schema 中的多个实用系统视图、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特别是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升约 4.5 倍，Sysbench 性能提升约 1.5 倍，OLAP 方面，TPC-H 50G Q15 因实现 View 可以执行，至此 TPC-H 22 个 Query 均可正常运行。新功能方面增加了窗口函数、视图（实验特性）、分区表、插件系统、悲观锁（实验特性）。
截止本文发稿时 TiDB 已在 500+ 用户的生产环境中长期稳定运行，涵盖金融、保险、制造，互联网， 游戏 等领域，涉及交易、数据中台、 历史 库等多个业务场景。不同业务场景对关系型数据库的诉求可用 “百花齐放”来形容，但对关系数据库最根本的诉求未发生任何变化，如数据可靠性，系统稳定性，可扩展性，安全性，易用性等。请跟随我们的脚步梳理 TiDB 3.0 有什么样的惊喜。
3.0 与 2.1 版本相比，显著提升了大规模集群的稳定性，支持单集群 150+ 存储节点，300+TB 存储容量长期稳定运行，主要的优化点如下：
1. 优化 Raft 副本之间的心跳机制，按照 Region 的活跃程度调整心跳频率，减小冷数据对集群的负担。
2. 热点调度策略支持更多参数配置，采用更高优先级，并提升热点调度的准确性。
3. 优化 PD 调度流程，提供调度限流机制，提升系统稳定性。
4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 时间，提升系统稳定性。
众所周知，数据库查询计划的稳定性对业务至关重要，TiDB 3.0 版本采用多种优化手段提升查询计划的稳定性，如下：
1. 新增 Fast Analyze 功能，提升收集统计信息的速度，降低集群资源的消耗及对业务的影响。
2. 新增 Incremental Analyze 功能，提升收集单调递增的索引统计信息的速度，降低集群资源的消耗及对业务的影响。
3. 在 CM-Sketch 中新增 TopN 的统计信息，缓解 CM-Sketch 哈希冲突导致估算偏大，提升代价估算的准确性，提升查询计划的稳定性。
4. 引入 Skyline Pruning 框架，利用规则防止查询计划过度依赖统计信息，缓解因统计信息滞后导致选择的查询计划不是最优的情况，提升查询计划的稳定性。
5. 新增 SQL Plan Management 功能，支持在查询计划不准确时手动绑定查询计划，提升查询计划的稳定性。
1. OLTP
3.0 与 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升约 1.5 倍，TPC-C 性能提升约 4.5 倍。主要的优化点如下：
1. TiDB 持续优化 SQL 执行器，包括：优化 NOT EXISTS 子查询转化为 Anti Semi Join，优化多表 Join 时 Join 顺序选择等。
2. 优化 Index Join 逻辑，扩大 Index Join 算子的适用场景并提升代价估算的准确性。
3. TiKV 批量接收和发送消息功能，提升写入密集的场景的 TPS 约 7%，读密集的场景提升约 30%。
4. TiKV 优化内存管理，减少 Iterator Key Bound Option 的内存分配和拷贝，多个 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。
5. 引入 Titan 存储引擎插件，提升 Value 值超过 1KB 时性能，缓解 RocksDB 写放大问题，减少磁盘 IO 的占用。
6. TiKV 新增多线程 Raftstore 和 Apply 功能，提升单节点内可扩展性，进而提升单节点内并发处理能力和资源利用率，降低延时，大幅提升集群写入能力。
TiDB Lightning 性能与 2019 年年初相比提升 3 倍，从 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，优化点，如下：
1. 提升 SQL 转化成 KV Pairs 的性能，减少不必要的开销。
2. 提升单表导入性能，单表支持批量导入。
3. 提升 TiKV-Importer 导入数据性能，支持将数据和索引分别导入。
4. TiKV-Importer 支持上传 SST 文件限速功能。
RBAC（Role-Based Access Control，基于角色的权限访问控制） 是商业系统中最常见的权限管理技术之一，通过 RBAC 思想可以构建最简单“用户-角色-权限”的访问权限控制模型。RBAC 中用户与角色关联，权限与角色关联，角色与权限之间一般是多对多的关系，用户通过成为什么样的角色获取该角色所拥有的权限，达到简化权限管理的目的，通过此版本的迭代 RBAC 功能开发完成。
IP 白名单功能（企业版特性） ：TiDB 提供基于 IP 白名单实现网络安全访问控制，用户可根据实际情况配置相关的访问策略。
Audit log 功能（企业版特性） ：Audit log 记录用户对数据库所执行的操作，通过记录 Audit log 用户可以对数据库进行故障分析，行为分析，安全审计等，帮助用户获取数据执行情况。
加密存储（企业版特性） ：TiDB 利用 RocksDB 自身加密功能，实现加密存储的功能，保证所有写入到磁盘的数据都经过加密，降低数据泄露的风险。
完善权限语句的权限检查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 语句权限检查。
1. 新增 SQL 方式查询慢查询，丰富 TiDB 慢查询日志内容，如：Coprocessor 任务数，平均/最长/90% 执行/等待时间，执行/等待时间最长的 TiKV 地址，简化慢查询定位工作，提高排查慢查询问题效率，提升产品易用性。
2. 新增系统配置项合法性检查，优化系统监控项等，提升产品易用性。
3. 新增对 TableReader、IndexReader 和 IndexLookupReader 算子内存使用情况统计信息，提高 Query 内存使用统计的准确性，提升处理内存消耗较大语句的效率。
4. 制定日志规范，重构日志系统，统一日志格式，方便用户理解日志内容，有助于通过工具对日志进行定量分析。
5. 新增 EXPLAIN ANALYZE 功能，提升SQL 调优的易用性。
6. 新增 SQL 语句 Trace 功能，方便排查问题。
7. 新增通过 unix_socket 方式连接数据库。
8. 新增快速恢复被删除表功能，当误删除数据时可通过此功能快速恢复数据。
TiDB 3.0 新增 TiFlash 组件，解决复杂分析及 HTAP 场景。TiFlash 是列式存储系统，与行存储系统实时同步，具备低延时，高性能，事务一致性读等特性。 通过 Raft 协议从 TiKV 中实时同步行存数据并转化成列存储格式持久化到一组独立的节点，解决行列混合存储以及资源隔离性问题。TiFlash 可用作行存储系统（TiKV）实时镜像，实时镜像可独立于行存储系统，将行存储及列存储从物理隔离开，提供完善的资源隔离方案，HTAP 场景最优推荐方案；亦可用作行存储表的索引，配合行存储对外提供智能的 OLAP 服务，提升约 10 倍复杂的混合查询的性能。
TiFlash 目前处于 Beta 阶段，计划 2019 年 12 月 31 日之前 GA，欢迎大家申请试用。
未来我们会继续投入到系统稳定性，易用性，性能，弹性扩展方面，向用户提供极致的弹性伸缩能力，极致的性能体验，极致的用户体验。
稳定性方面 V4.0 版本将继续完善 V3.0 未 GA 的重大特性，例如：悲观事务模型，View，Table Partition，Titan 行存储引擎，TiFlash 列存储引擎；引入近似物理备份恢复解决分布数据库备份恢复难题；优化 PD 调度功能等。
性能方面 V4.0 版本将继续优化事务处理流程，减少事务资源消耗，提升性能，例如：1PC，省去获取 commit ts 操作等。
弹性扩展方面，PD 将提供弹性扩展所需的元信息供外部系统调用，外部系统可根据元信息及负载情况动态伸缩集群规模，达成节省成本的目标。
我们相信战胜“未知”最好的武器就是社区的力量，基础软件需要坚定地走开源路线。截止发稿我们已经完成 41 篇源码阅读文章。TiDB 开源社区总计 265 位 Contributor，6 位 Committer，在这里我们对社区贡献者表示由衷的感谢，希望更多志同道合的人能加入进来，也希望大家在 TiDB 这个开源社区能够有所收获。
TiDB 3.0 GA Release Notes：
近期正在探索前端、后端、系统端各类常用组件与工具，对其一些常见的组件进行再次整理一下，形成标准化组件专题，后续该专题将包含各类语言中的一些常用组件。欢迎大家进行持续关注。
本节我们分享的是基于Golang实现的高性能和弹性的流处理器 benthos ，它能够以各种代理模式连接各种 源 和 接收器，并对有效负载执行 水合、浓缩、转换和过滤 。
它带有 强大的映射语言 ，易于部署和监控，并且可以作为静态二进制文件、docker 映像或 无服务器函数 放入您的管道，使其成为云原生。
Benthos 是完全声明性的，流管道在单个配置文件中定义，允许您指定连接器和处理阶段列表：
Apache Pulsar, AWS (DynamoDB, Kinesis, S3, SQS, SNS), Azure (Blob storage, Queue storage, Table storage), Cassandra, Elasticsearch, File, GCP (Pub/Sub, Cloud storage), HDFS, HTTP (server and client, including websockets), Kafka, Memcached, MQTT, Nanomsg, NATS, NATS JetStream, NATS Streaming, NSQ, AMQP 0.91 (RabbitMQ), AMQP 1, Redis (streams, list, pubsub, hashes), MongoDB, SQL (MySQL, PostgreSQL, Clickhouse, MSSQL), Stdin/Stdout, TCP UDP, sockets and ZMQ4.
1、docker安装
具体使用方式可以参见该 文档
有关如何配置更高级的流处理概念（例如流连接、扩充工作流等）的指导，请查看 说明书部分。
有关在 Go 中构建您自己的自定义插件的指导，请查看 公共 API。
LiteIDE是一款专门为Go语言开发的跨平台轻量级集成开发环境（IDE），由QT编写。
LiteIDE主要特点： 支持主流操作系统
Windows
Linux
MacOS X Go编译环境管理和切换
管理和切换多个Go编译环境
支持Go语言交叉编译 与Go标准一致的项目管理方式
基于GOPATH的包浏览器
基于GOPATH的编译系统
基于GOPATH的Api文档检索 Go语言的编辑支持
类浏览器和大纲显示
Gocode(代码自动完成工具)的完美支持
Go语言文档查看和Api快速检索
代码表达式信息显示F1
源代码定义跳转支持F2
Gdb断点和调试支持
gofmt自动格式化支持 其他特征
支持多国语言界面显示
完全插件体系结构
支持编辑器配色方案
基于Kate的语法显示支持
基于全文的单词自动完成
支持键盘快捷键绑定方案
Markdown文档编辑支持
实时预览和同步显示
自定义CSS显示
可导出HTML和PDF文档
批量转换/合并为HTML/PDF文档 Sublime Text 2（以下简称Sublime）+ GoSublime + gocode + MarGo的组合。
其优点有： 自动化提示代码。 保存的时候自动格式化代码，让您编写的代码更加美观，符合Go的标准。 支持项目管理 支持语法高亮 熟悉Java的读者应该对于idea不陌生，idea是通过一个插件来支持go语言的高亮语法，代码提示和重构实现。
三次握手：
1. 主动发起连接请求端（客户端），发送 SYN 标志位，携带数据包、包号
2. 被动接收连接请求端（服务器），接收 SYN，回复 ACK，携带应答序列号。同时，发送SYN标志位，携带数据包、包号
3. 主动发起连接请求端（客户端），接收SYN 标志位，回复 ACK。
被动端（服务器）接收 ACK —— 标志着 三次握手建立完成（ Accept()/Dial() 返回 ）
四次挥手：
1. 主动请求断开连接端（客户端）， 发送 FIN标志，携带数据包
2. 被动接受断开连接端（服务器）， 发送 ACK标志，携带应答序列号。 —— 半关闭完成。
3. 被动接受断开连接端（服务器）， 发送 FIN标志，携带数据包
4. 主动请求断开连接端（客户端）， 发送 最后一个 ACK标志，携带应答序列号。—— 发送完成，客户端不会直接退出，等 2MSL时长。
等 2MSL待目的：确保服务器 收到最后一个ACK
滑动窗口：
通知对端本地存储数据的 缓冲区容量。—— write 函数在对端 缓冲区满时，有可能阻塞。
TCP状态转换：
1. 主动发起连接请求端：
CLOSED —— 发送SYN —— SYN_SENT(了解) —— 接收ACK、SYN，回发 ACK —— ESTABLISHED (数据通信)
2. 主动关闭连接请求端：
ESTABLISHED —— 发送FIN —— FIN_WAIT_1 —— 接收ACK —— FIN_WAIT_2 (半关闭、主动端)
—— 接收FIN、回复ACK —— TIME_WAIT (主动端) —— 等 2MSL 时长 —— CLOSED
3. 被动建立连接请求端：
CLOSED —— LISTEN —— 接收SYN、发送ACK、SYN —— SYN_RCVD —— 接收 ACK —— ESTABLISHED (数据通信)
4. 被动断开连接请求端：
ESTABLISHED —— 接收 FIN、发送 ACK —— CLOSE_WAIT —— 发送 FIN —— LAST_ACK —— 接收ACK —— CLOSED
windows下查看TCP状态转换：
netstat -an | findstr 端口号
Linux下查看TCP状态转换：
netstat -an | grep 端口号
TCP和UDP对比:
TCP: 面向连接的可靠的数据包传递。 针对不稳定的 网络层，完全弥补。ACK
UDP：无连接不可靠的报文传输。 针对不稳定的 网络层，完全不弥补。还原网络真实状态。
优点 缺点
TCP： 可靠、顺序、稳定 系统资源消耗大，程序实现繁复、速度慢
UDP：系统资源消耗小，程序实现简单、速度快 不可靠、无序、不稳定
使用场景：
TCP：大文件、可靠数据传输。 对数据的 稳定性、准确性、一致性要求较高的场合。
UDP：应用于对数据时效性要求较高的场合。 网络直播、电话会议、视频直播、网络游戏。
UDP-CS-Server实现流程：
1. 创建 udp地址结构 ResolveUDPAddr(“协议”， “IP：port”) —— udpAddr 本质 struct{IP、port}
2. 创建用于 数据通信的 socket ListenUDP(“协议”, udpAddr ) —— udpConn (socket)
3. 从客户端读取数据，获取对端的地址 udpConn.ReadFromUDP() —— 返回：n，clientAddr， err
4. 发送数据包给 客户端 udpConn.WriteToUDP("数据"， clientAddr)
UDP-CS-Client实现流程：
1. 创建用于通信的 socket。 net.Dial("udp", "服务器IP：port") —— udpConn (socket)
2. 以后流程参见 TCP客户端实现源码。
UDPserver默认就支持并发！
------------------------------------
命令行参数： 在main函数启动时，向整个程序传参。 【重点】
语法： go run xxx.go argv1 argv2 argv3 argv4 。。。
xxx.exe: 第 0 个参数。
argv1 ：第 1 个参数。
argv2 ：第 2 个参数。
argv3 ：第 3 个参数。
argv4 ：第 4 个参数。
使用： list := os.Args 提取所有命令行参数。
获取文件属性函数：
os.stat(文件访问绝对路径) —— fileInfo 接口
fileInfo 包含 两个接口。
Name() 获取文件名。 不带访问路径
Size() 获取文件大小。
网络文件传输 —— 发送端（客户端）
1. 获取命令行参数，得到文件名（带路径）filePath list := os.Args
2. 使用 os.stat() 获取 文件名（不带路径）fileName
3. 创建 用于数据传输的 socket net.Dial("tcp"， “服务器IP+port”) —— conn
4. 发送文件名(不带路径) 给接收端， conn.write()
5. 读取 接收端回发“ok”，判断无误。封装函数 sendFile(filePath, conn) 发送文件内容
6. 实现 sendFile(filePath, conn)
1) 只读打开文件 os.Open(filePath)
for {
2) 从文件中读数据 f.Read(buf)
3) 将读到的数据写到socket中 conn.write(buf[:n])
4）判断读取文件的 结尾。 io.EOF. 跳出循环
}
网络文件传输 —— 接收端（服务器）
1. 创建用于监听的 socket net.Listen() —— listener
2. 借助listener 创建用于 通信的 socket listener.Accpet() —— conn
3. 读取 conn.read() 发送端的 文件名， 保存至本地。
4. 回发 “ok”应答 发送端。
5. 封装函数，接收文件内容 recvFile(文件路径)
1) f = os.Create(带有路径的文件名)
for {
2）从 socket中读取发送端发送的 文件内容 。 conn.read(buf)
3) 将读到的数据 保存至本地文件 f.Write(buf[:n])
4) 判断 读取conn 结束， 代表文件传输完成。 n == 0 break
}
