所谓"公钥登录"，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。 要实现公钥登陆的前提是需要用户端需要先生成公/私钥对，正常情况下都是有的，目录为：用户目录下的 .ssh 文件夹，私钥没有后缀，公钥后缀为 .pub。 如果没有公私密钥的话可以使用 ssh-keygen 进行生成. 复制代码 ssh-keygen -f test // -f 制定公司钥名称，回车进入下一步 Enter passphrase (empty for no passphrase): // 这里是密钥口令，如果担心私钥安全可以设置一下 Enter same passphrase again: // 确认密钥口令，回车后完成生成 服务器导入公钥 命令行导入 3ssh-copy-id -i ~/.ssh/test.pub user@host 手动导入 通过账号密码登陆服务器，将公钥复制到 ~/.ssh 目录下,执行下方命令: cat RemotePPK.pub >> authorized_keys xshell 使用公钥登陆演示 输入用户名 选择公钥登陆 导入密钥 选择导入好的密钥点 Ok 点击OK 完成登陆

点进来看的小伙伴是否也想寻求管理中的银弹，期待能学到一招独门绝技，从此独步江湖。 实际上管理与开发一样的，也是不存在银弹的，管理是一个系统性问题，任何的系统性问题都不可能通过引入一个概念或一个制度来解决问题。 那管理还有办法能精进吗？那肯定还是有的，既然是要解决系统性问题，那就需要一个系统的制度去解决问题。 建立共识，打破信息壁垒 建立共识的极致就是将一个团队打造成一个具象的人，整个团队像一个人一样思考。 团队协作中，最大的成本就是沟通成本。每增加一个人，都会增加一份沟通成本。当整个团队像一个人的时候，也就意味着沟通成本趋近于 0 。 就像你左手递过一只笔，右手很自然的接过笔，整个过程不需要进行任何的沟通与思考。上面的例子是有些极限的，但是可以用这个衡量标准作为不断优化团队共识的目标。 制定规范 当团队有了共同的想法和相同的目标，我们还需要制定相应的规范。 拿行军打仗作比喻，共识当然就是打胜仗，规范则是为了打胜仗而锻炼出的战术配合与作战计划。 制定规范的目的就是为了让团队成员做出的成果能够保持在一定的水平，不会因为个体能力的差异而导致做出的成果参差不齐。 当制定了规范后，从外部看整个团队就会觉得团队是一个整体，有组织有纪律，而不是散兵游勇，毫无章法。 建立流程 在团队协作过程中，两个环节对接时经常会产生各种各样的问题，为了解决对接中存在的问题，不得不花费大量的时间进行沟通和调整，才能使工作顺利的推进下去。 建立流程就是为了解决这类问题，为每个工作交接的环节制定相应的标准，对接双方都按照标准进行准备，这样在对接的过程中会减少很多因流程缺失带来的沟通和重复劳动成本的增加。 提升团队凝聚力 在数学概念中 1 +1 =2 是我们在基础数学中就明白的等式，但是在团队协作中却未必成立，有的时候会出现 1 +1 < 2 和 1 + 1 > 2 的效果。 我们在团队协作中是追求 1 + 1 > 2 的效果的，最差我们也想要得到 1 + 1 =2 的结果，最不想的就是 1 + 1 < 2 的情况，如何做到呢？ 秘诀在于提升团队凝聚力，将团队的力量集中起来，利出于一孔，在需要释放的地方集中释放。 Summary 团队管理除了上面说的几个环节还会涉及到其他很多方面。这里只是抛砖引玉，更多的需要我们在不断的探索中总结和提炼。 做事情应该先从思想层面去解决问题，然后用思想去指导行动，通过行动解决遇到的种种问题。很多时候思想的高度直接决定你处理问题的能力大小。每种思想都有它的上限和下限，同一水平思想下，难以拉出数量级上的差距。只有将思想进行提升，才有可能迸发出越级输出的能力。 管理是一个求道的过程，初入管理的时候经常痴迷于追求术，想知道究竟有什么具体的招法来帮助自己度过初入管理的困境，而结果却是：有多努力就有多绝望。当有了管理是求道的认识后，便觉豁然开朗，从困境中解脱出来，从而触碰到管理的门径。 有句话想与君共勉：有道无术，术尚可求也，有术无道，止于术。愿你我一样，能早日找到自己的管理之道。

日常开发中经常会遇到单例模式的使用场景，单例模式可以保证我们初始化出来的结构体只有一个，在一些请求上下文，mysql 连接池..场景经常有着不可估量的作用。 在 golang 开发中，我们应当如何去设计单例模式呢？ 常见的错误书写方式 相信如果你对 PHP 写的比较多的情况下经常会写出下面代码一样的单例模式 package main type Singleton struct { } var ins *Singleton func GetIns() *Singleton { if ins == nil { ins = &Singleton{} } return ins } 那上述代码，在正常开发存在什么样的问题呢？上述代码如果用于 PHP 项目是没有任何问题的，因为 PHP 本事是请求隔离的，因而也不会存在并发的问题，但是如果放在常驻内存类型的语言中就会出现并发性不安全问题。 接下来考虑一个场景，在高并发场景下，同时又两个业务都执行到 ins == nil 而此时的 ins 确实没有实例化，那程序将会如何执行呢？答案显而易见，两个业务都会实例化出自己的 ins 结构体，这显然不符合我们的程序预期。 如何解决 golang 标准库sync中找到了Once类型。它能保证某个操作仅且只执行一次。有了他我们就可以很方便的解决并发的问题了接下看看代码示例： package main import "sync" type Singleton struct { } var ins *Singleton var once sync.Once func GetIns() *Singleton { once.Do(func() { ins = &Singleton{} }) return ins } 这样就可以利用 go 语言的特性，比较方便的实现单例模式了 Conclusion 到此，golang 的单例模式就完成了，在 golang 的开发中，我们最常考虑的就是,并发安全问题，是需要我们经常考虑的问题，编程是一件非常复杂的事情，只有深入的了细节，又能把控的了全局，才可以在开发过程中无往不利。

最近开发中，将一个 php 算法，移植到 golang 中，发现 base64 算法生成的字符串不一致，经过排查发现是由于 ASCII 控制字符导致的原因，加下来看代码 <?php $asciiArr =[10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151]; $str = ''; foreach ($asciiArr as $ascii) { $str .= chr($ascii); } echo base64_encode($str); 上述代码输出： CrvZDM+3uOe4lXaX package main import ( "encoding/base64" "fmt" ) func main() { res := []int{10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151} var str string var b []byte for _, v := range res { str += string(v) b = append(b, byte(v)) } byteCode := base64.StdEncoding.EncodeToString([]byte(b)) strCode := base64.StdEncoding.EncodeToString([]byte(str)) fmt.Println("byteCode:", byteCode) fmt.Println("stringCode:", strCode) } 上述代码输出： byteCode: CrvZDM+3uOe4lXaX stringCode: CsK7w5kMw4/Ct8K4w6fCuMKVdsKX 由此可以看出，关于 ASCII 控制字符的转码，不可以用 string 转 byte 到 EncodeToString 方法，如果需要一致输出，需要直接用 []byte 接收值传入 EncodeToString 即可