#2023年golang插件（golang插件化框架）- 知乎
920GG游戏网相关导读
intellij idea15的golang插件怎么配置
将下载golang插件的zip包解压，然后执行 File - open 操作打开该项目
打开该项目后，进行 SDK 和 模块配置
执行操作 File - Project Structure 打开项目结构配置窗口
如下图配置，SDKs 中设置 JDK、 IDEA 这两个的路径（图上的 Go sdk 你先别管他，你现在还操作不golang插件了的）
IDEA 的sdk 其实就是软件安装目录
然后是模块设置 Modules
设置当前模块的SDK依赖，如果不设置这里，则编译时会出现下面的错误golang插件：
我在这里莫名其妙了好半天才找到原因
然后选择 ro.redeul.google.go 包进行编译，如图：
这里如果没有出现 error 则编译成功。
3. 生成插件 jar 安装包
选择 Build - Prepare Plugin module ... For Deployment 将会生成一个google-go-language.jar 的文件在项目根目录下
4. 安装插件：
选择 File-settings - Plugins - install plugins from disk 在右下角
选择刚刚生成的 jar 文件将自动安装插件，然后重启软件就好了
5. 下载安装 go sdk
选择你对应的系统版本安装吧，
然后一些系统环境变量配置，
参考：
新建 变量名：GOBIN 变量值 ：C:\Go\bin
新建 变量名：GOARCH 变量值：386
如果是64位系统 变量值为amd64
新建 变量名：GOOS 变量值：windows
新建 变量名： GOROOT 变量值：C:\Go
新建 变量名： GOPATH 变量值：C:\my\go\project
\my\go\project 是你的项目目录
编辑 Path 在Path的变量值的最后加上 ;C:\Go\bin
之后你新建项目就可以看到 go 的图标啦
新建好项目 hello world 一下吧 o(∩_∩)o 哈哈 ，可以开始开发你牛逼的 GO 项目了
好了先就这样吧
golangci-line 工具介绍
在 ci 过程中，经常有一些可以通过静态分析或者白盒检测去避免一些问题以及规范代码格式！使用Go语言一般是使用 golangci-line 作为代码检测工具！
参考官网golang插件：
安装： curl-sSfL | sh -s -- -b $(go env GOPATH)/bin v1.43.0
版本信息: golangci-lint--version
目前我司是自己二开的 golangci-line，所以这里使用的开源版本，其实大同小异，就是开发golang插件了一些插件！
这个就是一个工具，集成golang插件了各类自动检测代码的工具，所以不需要本地安装太多的工具，只需要这个工具即可！
由于它需要一个go的项目，这里以我自己的项目去介绍， 项目地址：，如果有同学想自己尝试下可以直接下载我这个项目！项目也比较规范！
其实执行 golangci-lint run-h 就可以获取以下帮助
例如我经常使用的: 我日常就是开启format功能！
1、默认使用的插件
2、默认没用的
3、presets 分类：
具体可以参考我的:
主要是做一些 无用代码检测，简化代码，格式化代码！然后执行 golangci-lint run --fix 即可
深入理解golang
最近三年，在工作中使用go开发了不少服务。深感go的便捷，以及它的runtime的复杂。我觉得需要定期的进行总结，因此决定写这篇文章，也许更准确的，应该叫笔记。
最近终于解决了一个和cgo有关的问题。这个问题从发现到解决前后经历了接近4个月，当然，和人手不足也有关系。而对于我个人而言，这个问题其实历时2年！这得从头说起。
在上一家公司的一个项目里，有一个服务做音视频数据的提取，这个服务运行在嵌入式设备TX2上。音视频提取这一关键功能主要利用nvidia基于gstreamer开发的插件，这个插件可以发挥nvidia gpu的硬件解码功能。当时这个服务使用go和c混编的方式，问题的症状是服务运行一段时间后，不输出音视频数据。遗憾的是，由于疫情，项目停止，因此没有机会继续研究这个问题。
时间来到去年底。当前这个项目进行压力测试，发现关键的语音处理服务运行一段时间后，会出现不拉流的情况，因此也没有后续的结果输出。症状和上一个项目非常像。虽然使用的第三方SDK不一样，但同样用了go和c混编的方式。一开始，焦点就放在go的运行时上，觉得可能是go和c相互调用的方式不对。经过合理猜测，并用测试进行验证后，发现问题还是在第三方拉流的SDK上，它们的回调函数必须要快，否则有可能会阻塞它们的回调线程。当然，在go调用c的时候，如果耗时比较长，会对go的运行时造成一些副作用；在c回调go的时候，go的运行时也有可能阻塞c的回调线程。但go的运行时已经比较成熟，因此我觉得它对这个问题的贡献不大。以上采用了假设-验证的方法，主要的原因还是第三方的拉流SDK不开源。在定位问题的过程中，使用了gdb的gcore来生成堆栈；也搭建了灰度环境来进行压力测试，以及完善监控，这些都是解决方法的一部分。
正是这一问题，促使我更多的了解go的运行时。而我看得越多，越觉得go的运行时是一个庞大的怪物。因此，抱着能了解一点是一点的心态，不断的完善这篇笔记。
