Golang值类型和引用类型

2020-1-21 liyangcoder Golang

1.值类型和引用类型


   值类型：变量直接存储，内存通常在栈中分配。

   引用类型：变量存储的是一个地址，这个地址存储最终的值。内存通常在堆上分配。通过GC回收


PS : 通常在函数中转入指针效率比较高，因为方法中的参数是需要进行拷贝的，拷贝指针的效率比较高，要是一个大的接口体的话拷贝的效率就比较低

2.GoLang中的值类型和引用类型


   1.值类型 ： 基本数据类型int、float、bool、string以及array和struct。

   2.引用类型：指针、slice、map、chan等都是引用类型

注意:Go语言中slice，map这三种类型的实现机制类似指针，所以可以直接传递，而不用取地址后传递指针。（注：若函数需改变slice的长度，则仍需要取地址传递指针）




评论(0) 浏览(711)

laravel框架创建索引长度报错

2019-12-18 liyangcoder PHP

索引长度 & MySQL / MariaDB


Laravel 默认使用 utf8mb4 字符，它支持在数据库中存储 "emojis" 。 如果你是在版本低于 5.7.7 的 MySQL release 或者版本低于 10.2.2 的 MariaDB release 上创建索引，那就需要你手动配置迁移生成的默认字符串长度。 即在 AppServiceProvider 中调用 Schema::defaultStringLength 方法来配置它 ： 

use Illuminate\Support\Facades\Schema;

/**
 * 引导任何应用程序服务。
 *
 * @return void
 */
public function boot()
{
    Schema::defaultStringLength(191);
}

评论(0) 浏览(965)

上传文件报413 Request Entity Too Large错误解决办法(nginx服务器)

2019-11-12 liyangcoder PHP

修改nginx.conf的值就可以解决了

将以下代码粘贴到nginx.conf内

阅读全文>>

评论(0) 浏览(985)

gin关联查询的一个小小的知识点

2019-9-26 liyangcoder Golang

在做一个老项目迁移，从PHP迁移到Golang，于是不得不一边迁移一边深入的了解老系，发现老系统有很多奇葩的设计，今天说说其中一个，以及给我带来的困扰和解决方案。

有三张表

1.用户表(user)

阅读全文>>

标签: golang

评论(0) 浏览(1137)

语义化版本 2.0.0

2019-9-22 liyangcoder Web周边

摘要

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

  1. 主版本号：当你做了不兼容的 API 修改，
  2. 次版本号：当你做了向下兼容的功能性新增，
  3. 修订号：当你做了向下兼容的问题修正。

先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

简介

在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，加入的包越多，你就越有可能在未来的某一天发现自己已深陷绝望之中。

在依赖高的系统中发布新版本包可能很快会成为噩梦。如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个依赖包改版才能完成某次升级）。而如果依赖关系过于松散，又将无法避免版本的混乱（假设兼容于未来的多个版本已超出了合理数量）。当你专案的进展因为版本依赖被锁死或版本混乱变得不够简便和可靠，就意味着你正处于依赖地狱之中。

作为这个问题的解决方案之一，我提议用一组简单的规则及条件来约束版本号的配置和增长。这些规则是根据（但不局限于）已经被各种封闭、开放源码软件所广泛使用的惯例所设计。为了让这套理论运作，你必须先有定义好的公共 API 。这可以透过文件定义或代码强制要求来实现。无论如何，这套 API 的清楚明了是十分重要的。一旦你定义了公共 API，你就可以透过修改相应的版本号来向大家说明你的修改。考虑使用这样的版本号格式：X.Y.Z （主版本号.次版本号.修订号）修复问题但不影响API 时，递增修订号；API 保持向下兼容的新增及修改时，递增次版本号；进行不向下兼容的修改时，递增主版本号。

我称这套系统为“语义化的版本控制”，在这套约定下，版本号及其更新方式包含了相邻版本间的底层代码和修改内容的信息。

语义化版本控制规范（SemVer）

以下关键词 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、OPTIONAL 依照 RFC 2119 的叙述解读。（译注：为了保持语句顺畅， 以下文件遇到的关键词将依照整句语义进行翻译，在此先不进行个别翻译。）

  1. 使用语义化版本控制的软件必须（MUST）定义公共 API。该 API 可以在代码中被定义或出现于严谨的文件内。无论何种形式都应该力求精确且完整。

  2. 标准的版本号必须（MUST）采用 X.Y.Z 的格式，其中 X、Y 和 Z 为非负的整数，且禁止（MUST NOT）在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素必须（MUST）以数值来递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。

  3. 标记版本号的软件发行后，禁止（MUST NOT）改变该版本软件的内容。任何修改都必须（MUST）以新版本发行。

  4. 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。

  5. 1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。

  6. 修订号 Z（x.y.Z | x > 0）必须（MUST）在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。

  7. 次版本号 Y（x.Y.z | x > 0）必须（MUST）在有向下兼容的新功能出现时递增。在任何公共 API 的功能被标记为弃用时也必须（MUST）递增。也可以（MAY）在内部程序有大量新功能或改进被加入时递增，其中可以（MAY）包括修订级别的改变。每当次版本号递增时，修订号必须（MUST）归零。

  8. 主版本号 X（X.y.z | X > 0）必须（MUST）在有任何不兼容的修改被加入公共 API 时递增。其中可以（MAY）包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号必须（MUST）归零。

  9. 先行版本号可以（MAY）被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符来修饰。标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止（MUST NOT）留白。数字型的标识符禁止（MUST NOT）在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法满足预期的兼容性需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。

  10. 版本编译元数据可以（MAY）被标注在修订版或先行版本号之后，先加上一个加号再加上一连串以句点分隔的标识符来修饰。标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止（MUST NOT）留白。当判断版本的优先层级时，版本编译元数据可（SHOULD）被忽略。因此当两个版本只有在版本编译元数据有差别时，属于相同的优先层级。范例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。

  11. 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须（MUST）把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较（版本编译元数据不在这份比较的列表中）。由左到右依序比较每个标识符，第一个差异值用来决定优先层级：主版本号、次版本号及修订号以数值比较，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当主版本号、次版本号及修订号都相同时，改以优先层级比较低的先行版本号决定。例如：1.0.0-alpha < 1.0.0。有相同主版本号、次版本号及修订号的两个先行版本号，其优先层级必须（MUST）透过由左到右的每个被句点分隔的标识符来比较，直到找到一个差异值后决定：只有数字的标识符以数值高低比较，有字母或连接号时则逐字以 ASCII 的排序来比较。数字的标识符比非数字的标识符优先层级低。若开头的标识符都相同时，栏位比较多的先行版本号优先层级比较高。范例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。

为什么要使用语义化的版本控制？

这并不是一个新的或者革命性的想法。实际上，你可能已经在做一些近似的事情了。问题在于只是“近似”还不够。如果没有某个正式的规范可循，版本号对于依赖的管理并无实质意义。将上述的想法命名并给予清楚的定义，让你对软件使用者传达意向变得容易。一旦这些意向变得清楚，弹性（但又不会太弹性）的依赖规范就能达成。

举个简单的例子就可以展示语义化的版本控制如何让依赖地狱成为过去。假设有个名为“救火车”的函式库，它需要另一个名为“梯子”并已经有使用语义化版本控制的包。当救火车创建时，梯子的版本号为 3.1.0。因为救火车使用了一些版本 3.1.0 所新增的功能， 你可以放心地指定依赖于梯子的版本号大等于 3.1.0 但小于 4.0.0。这样，当梯子版本 3.1.1 和 3.2.0 发布时，你可以将直接它们纳入你的包管理系统，因为它们能与原有依赖的软件兼容。

作为一位负责任的开发者，你理当确保每次包升级的运作与版本号的表述一致。现实世界是复杂的，我们除了提高警觉外能做的不多。你所能做的就是让语义化的版本控制为你提供一个健全的方式来发行以及升级包，而无需推出新的依赖包，节省你的时间及烦恼。

如果你对此认同，希望立即开始使用语义化版本控制，你只需声明你的函式库正在使用它并遵循这些规则就可以了。请在你的 README 文件中保留此页连结，让别人也知道这些规则并从中受益。

FAQ

在 0.y.z 初始开发阶段，我该如何进行版本控制？

最简单的做法是以 0.1.0 作为你的初始化开发版本，并在后续的每次发行时递增次版本号。

如何判断发布 1.0.0 版本的时机？

当你的软件被用于正式环境，它应该已经达到了 1.0.0 版。如果你已经有个稳定的 API 被使用者依赖，也会是 1.0.0 版。如果你很担心向下兼容的问题，也应该算是 1.0.0 版了。

这不会阻碍快速开发和迭代吗？

主版本号为零的时候就是为了做快速开发。如果你每天都在改变 API，那么你应该仍在主版本号为零的阶段（0.y.z），或是正在下个主版本的独立开发分支中。

对于公共 API，若即使是最小但不向下兼容的改变都需要产生新的主版本号，岂不是很快就达到 42.0.0 版？

这是开发的责任感和前瞻性的问题。不兼容的改变不应该轻易被加入到有许多依赖代码的软件中。升级所付出的代价可能是巨大的。要递增主版本号来发行不兼容的改版，意味着你必须为这些改变所带来的影响深思熟虑，并且评估所涉及的成本及效益比。

为整个公共 API 写文件太费事了！

为供他人使用的软件编写适当的文件，是你作为一名专业开发者应尽的职责。保持专案高效一个非常重要的部份是掌控软件的复杂度，如果没有人知道如何使用你的软件或不知道哪些函数的调用是可靠的，要掌控复杂度会是困难的。长远来看，使用语义化版本控制以及对于公共 API 有良好规范的坚持，可以让每个人及每件事都运行顺畅。

万一不小心把一个不兼容的改版当成了次版本号发行了该怎么办？

一旦发现自己破坏了语义化版本控制的规范，就要修正这个问题，并发行一个新的次版本号来更正这个问题并且恢复向下兼容。即使是这种情况，也不能去修改已发行的版本。可以的话，将有问题的版本号记录到文件中，告诉使用者问题所在，让他们能够意识到这是有问题的版本。

如果我更新了自己的依赖但没有改变公共 API 该怎么办？

由于没有影响到公共 API，这可以被认定是兼容的。若某个软件和你的包有共同依赖，则它会有自己的依赖规范，作者也会告知可能的冲突。要判断改版是属于修订等级或是次版等级，是依据你更新的依赖关系是为了修复问题或是加入新功能。对于后者，我经常会预期伴随着更多的代码，这显然会是一个次版本号级别的递增。

如果我变更了公共 API 但无意中未遵循版本号的改动怎么办呢？（意即在修订等级的发布中，误将重大且不兼容的改变加到代码之中）

自行做最佳的判断。如果你有庞大的使用者群在依照公共 API 的意图而变更行为后会大受影响，那么最好做一次主版本的发布，即使严格来说这个修复仅是修订等级的发布。记住， 语义化的版本控制就是透过版本号的改变来传达意义。若这些改变对你的使用者是重要的，那就透过版本号来向他们说明。

我该如何处理即将弃用的功能？

弃用现存的功能是软件开发中的家常便饭，也通常是向前发展所必须的。当你弃用部份公共 API 时，你应该做两件事：（1）更新你的文件让使用者知道这个改变，（2）在适当的时机将弃用的功能透过新的次版本号发布。在新的主版本完全移除弃用功能前，至少要有一个次版本包含这个弃用信息，这样使用者才能平顺地转移到新版 API。

语义化版本对于版本的字串长度是否有限制呢？

没有，请自行做适当的判断。举例来说，长到 255 个字元的版本已过度夸张。再者，特定的系统对于字串长度可能会有他们自己的限制。


转自:https://semver.org/lang/zh-CN/

评论(0) 浏览(715)

go语言string、int、int64互相转换

2019-8-25 liyangcoder Golang

import "strconv"  //先导入strconv包


// string到int

int, err := strconv.Atoi(string)


// string到int64

int64, err := strconv.ParseInt(string, 10, 64)


// int到string

string := strconv.Itoa(int)


// int64到string

string := strconv.FormatInt(int64,10)

标签: go golang

评论(0) 浏览(4955)

http强转https导致post变get的问题

2019-7-13 liyangcoder PHP

https是大势所趋，现在主流网站都已支持https，但是用户并没有养成输入https的习惯，仍然是输入http，这时候就需要我们将用户的请求强行转成https，以保证用户的数据安全。

今天遇到这样一个问题，在我的一个https页面做登陆的时候，用post方法发送一个表单，但是不论如何和登陆不成功，经过一段时间调试，发现我页面中的表单提交地址是http的，我当然可以直接改提交地址，但是我觉得这应该不是一个完美的做法，于是参考了一下百度的做法。

1.png

百度这里用的并不是301/302，而是307，于是我也试了一下： 

server {
	listen 80;
	server_name xxx.com;
	return 307 https://request_uri$request_uri; #关键
}
2.png


提交表单没问题了，大功告成。

评论(1) 浏览(8052)

(支付宝)RSA密钥调试工具的一个坑

2019-6-27 liyangcoder PHP

最近在开发支付宝支付,在支付宝后台配置的时候,发现了一个问题,困扰了我半天,终于找到了问题,来记录一下.

支付宝开放平台后台需要我们填RSA公钥(由于我填过了,所以这里是修改),如下图:

深度截图_选择区域_20190627150706.png

深度截图_选择区域_20190627150854.png

下一步将我辛辛苦苦生成的公钥添加进去,贴心的支付宝还给我提供了一个"验证功能"避免我们在对接的时候由于公钥/私钥不对而导致的失败:

深度截图_选择区域_20190627151113.png

深度截图_选择区域_20190627151335.png

调试工具上面写着:"请将JSON串 {"a":"123"}使用填写公钥对应的私钥签名".

赶紧用我自己的签名方法签名试一下.

深度截图_选择区域_20190627151713.png深度截图_选择区域_20190627151729.png

嗯!很好,我的程序一如既往的让我满意.

于是我把这个签名粘贴到支付宝的调试工具里测试.

WHAT?失败了!

深度截图_选择区域_20190627151942.png

紧接着,我花了几个小时来找bug,曾一度怀疑我的签名和验签方法就是个摆设.但是然并卵,于是我翻出支付宝官方给的demo找问题,结果找到了如下一段:

深度截图_选择区域_20190627152430.png

按照这段逻辑来理解的话,那应该是将json串'{"a":"123"}',转成对应的URL参数a=123,于是我再次尝试,

深度截图_选择区域_20190627152740.png

我的程序自然很赏脸,将签名粘贴到支付宝调试工具,终于通过了

深度截图_选择区域_20190627152947.png

法克!支付宝啊支付宝,能不能严谨点?害得我浪费了大半天的时间啊!

如果你也遇到了同样的问题,希望本问恰好帮助到了你.

标签: 支付宝

评论(0) 浏览(5978)

layui动态设置checkbox选中状态

2019-5-5 liyangcoder JavaScript

今天在使用jquery动态设置layui的checkbox元素的选中状态时始终只能取消选中，却不能重新勾选，点击勾选则没有问题，代码如下 

if (value == "true") {
    $("#select1").attr("checked", "checked");
} else {
    $("#select1").removeAttr("checked");
}

百度很久终于找到一个可用的解决方案,使用prop代替attr，如下： 

if (value == "true") {
    //$id.attr("checked", "checked");
    $id.prop("checked", true);
} else {
    $id.prop("checked", false);
    //$id.removeAttr("checked");
}

转自：https://www.cnblogs.com/missile/p/10062723.html


评论(0) 浏览(5731)

Chrome浏览器ERR_BLOCKED_BY_CLIENT || Firefox同源

2019-4-28 liyangcoder HTML

今天遇到一个问题，一个接口使用ajax请求失败，使用postman则没问题。

Chrome中显示的错误是net::ERR_BLOCKED_BY_CLIENT

TIM截图20190428095213.png

搞了半天没搞明白是什么问题，又换Firefox继续调试，结果告诉我跨域了

TIM截图20190428095438.png

可是很奇怪，我其他同域名的接口都没问题，就是这个不行，调试了半天，基本排除了跨域的问题。

郁闷了好久，终于发现了问题，原来问题出在URL上，我的URL中包含ad关键字，被广告屏蔽插件当成广告给拦截了。

TIM截图20190428095749.png

其实之前遇到过类似问题的，这次又大意了。之前是页面class名字中包含ad，导致整个div不显示。

总结一下：

页面接口、class名称、id名称、文件名（css、js、img）中都要避免出现ad、advertisement以及其它相关的字样，避免被广告插件拦截。

评论(0) 浏览(1747)

Powered by emlog 冀ICP备13011830号-1