环境配置tips

一、 MySQL在Linux下数据库名、表名、列名、别名大小写规则是这样的&＃xff1a;
　　 1、数据库名与表名是严格区分大小写的&＃xff1b;
　　 2、表的别名是严格区分大小写的&＃xff1b;
　　 3、列名与列的别名在所有的情况下均是忽略大小写的&＃xff1b;
　　 4、变量名也是严格区分大小写的&＃xff1b;
修改不区分大小写,在my.cnf中的[mysqld]后面添加lower_case_table_names&＃61;1&＃xff0c;重启MYSQL服务。

二、 Devcloud 安装MySQL出现Job for mysqld.service failed because the control process exited with error code问题&＃xff0c;如下图所示。可以vim /var/log/mysqld.log查看启动报错。
解决方法&＃xff1a;1.删除 rm -r /var/lib/mysql / 2.重启MySQL服务systemctl restart mysqld.service

三、 Devcloud yum失效&＃xff1a;Devcloud使用yum安装软件包&＃xff0c;报错[Errno 14] HTTP Error 403 -Forbidden。故障原因&＃xff1a;YUM源文件异常

解决方案&＃xff1a;

1. 在云Devnet执行cd /etc/yum.repos.d/ 进入目录&＃xff0c;tar -czvf filename *.repo 备份原repo文件&＃xff0c;然后执行rm -rf *.repo 删除repo文件&＃xff1b;
   # cd /etc/yum.repos.d/
   # tar -czvf backup.repo.back *.repo
   # rm -rf *.repo
2. 上传“epel.repo”&＃xff0c;“tlinux.repo”&＃xff0c;“tlinux-kvm-guest.repo”这三个文件到云开发机/etc/yum.repos.d/目录下。
3. 执行yum clean all和yum makecache 更新yum缓存

四、vscode中golang的配置
VS Code提供了三种setting.json设置方式&＃xff1a;后者的设置会覆盖前者的设置&＃xff0c;若没有设置某一项&＃xff0c;将继续使用前者的设置。我们可以这样理解此层次

• 用户设置&＃xff1a; 这种方式进行的设置&＃xff0c;会应用于该用户打开的所有工程&＃xff1b;

• 远程设置&＃xff1a; 这种方式进行的设置&＃xff0c;会应用于该用户打开的远程工程&＃xff1b;

• 工作空间设置&＃xff1a;工作空间是指使用VS Code打开的某个文件夹&＃xff0c;在该文件夹下会创建一个名为.vscode的隐藏文件夹&＃xff0c;里面包含着仅适用于当前目录的VS Code的设置&＃xff0c;工作空间的设置会覆盖用户的设置。

用户设置即全局设置&＃xff0c;用户自行设定好后&＃xff0c;每次打开VSCode即使用的此设定&＃xff0c;若某项无设定即使用默认设置.
工作区设置即工作环境设置&＃xff0c;可对不同的工作环境是用不同的工作环境&＃xff0c;若某项无设定&＃xff0c;即使用上述设置.
文件夹设置即为项目设置&＃xff0c;将一个文件夹当成一个项目&＃xff0c;对同一个工作环境下的不同项目&＃xff0c;使用不同的设置&＃xff0c;若某项无设定&＃xff0c;即使用上述设置。

launch.json是vscode用于调试的配置文件&＃xff0c;比如指定调试语言环境&＃xff0c;指定调试类型等等。多个golang项目的文件夹项目&＃xff0c;建议关闭languageserver&＃xff0c;因为languageserver会使用gopls&＃xff0c;而gopls&＃xff08;gopls requires a module at the root of your workspace.&＃xff09;。

关于VS code报错gopls requires a module at the root of your workspace设置里面添加如下"gopls": { "experimentalWorkspaceModule": true }.

Set languageServer is true. I realized that if the go.mod is not at the root of your project VSCode does not work properly.
That might now (Oct. 2020) be supported, as a consequence of gopls v0.5.1 and its experimental feature Multi-module workspace support from the proposal 32394.
Even if you don’t have multiple modules, a go.mod in a sub-folder (instead of the root folder of your project) will be better managed (if you activate the gopls.experimentalWorkspaceModule setting).
ExperimentalWorkspaceModule opts a user into the experimental support for multi-module workspaces.

五、GOROOT、GOPATH和GOMODULE
在安装完Golang语言的时候&＃xff0c;所谓的安装路径其实就是你的GOROOT路径&＃xff0c;也就是说GOROOT存放的Golang语言内置的程序库的所在位置&＃xff0c;而通常你安装完后&＃xff0c;你电脑的环境变量就会设好GOROOT路径。

在使用 GOPATH 模式下&＃xff0c;我们需要将应用代码存放在固定的GOPATH/src目录下&＃xff0c;并且如果执行go get来拉取外部依赖会自动下载并安装到GOPATH目录下。import导入时编译器从GOPATH/src下开始搜索&＃xff0c;参数是src为起始的绝对路径。编译器从标准库开始搜索&＃xff0c;然后是GOPATH相关目录。GOPATH管理的问题&＃xff1a;GOPATH 模式下没有版本控制的概念&＃xff0c;具有致命的缺陷&＃xff0c;至少会造成以下问题&＃xff1a;在执行go get的时候&＃xff0c;你无法传达任何的版本信息的期望&＃xff0c;也就是说你也无法知道自己当前更新的是哪一个版本&＃xff0c;也无法通过指定来拉取自己所期望的具体版本。在运行 Go 应用程序的时候&＃xff0c;你无法保证其它人与你所期望依赖的第三方库是相同的版本&＃xff0c;也就是说在项目依赖库的管理上&＃xff0c;你无法保证所有人的依赖版本都一致。你没办法处理 v1、v2、v3 等等不同版本的引用问题&＃xff0c;因为 GOPATH 模式下的导入路径都是一样的&＃xff0c;都是github.com/foo/bar。

Go Modules是语义化版本管理的依赖项的包管理工具&＃xff1b;它解决了GOPATH存在的缺陷&＃xff0c;可以为每个项目定制化依赖的代码版本包。在使用模块module时的时候&＃xff0c;GOPATH 是无意义的&＃xff0c;不过还是会把下载的依赖储存在 $GOPATH/pkg/mod 中&＃xff0c;也会把 go install 的结果放在 $GOPATH/bin 。变量 GO111MODULE&＃xff1a;

• GO111MODULE&＃61;off&＃xff1a;无模块支持&＃xff0c;go 会从 GOPATH 和 vendor 文件夹寻找包。
• GO111MODULE&＃61;on&＃xff1a;模块支持&＃xff0c;go 会忽略 GOPATH 和 vendor 文件夹&＃xff0c;只根据 go.mod 下载依赖。无论项目在GOPATH/src里面还是在外面&＃xff0c;都会使用go.mod 里 require的包。
• GO111MODULE&＃61;auto&＃xff1a;auto 自动模式下&＃xff0c;项目在GOPATH/src里会使用GOPATH/src的依赖包&＃xff0c;在GOPATH/src外&＃xff0c;就使用go.mod 里 require的包。在 GOPATH/src 外面且根目录有 go.mod 文件时&＃xff0c;开启模块支持。