golang请求参数验证,golang函数默认参数

本文目录一览：

• 
  1、golang http请求数据怎么传body体参数
  


• 
  2、golang echo(二)---请求与响应
  


• 
  3、golang net/http包 http请求的字节码读取与解析。
  


• 
  4、golang jwt鉴权分析
  


• 
  5、Golang 中更好的错误处理：理论和实践技巧
  

golang http请求数据怎么传body体参数

get请求一般是在你请求的地址后边加上?par=''par2=''例如请求的页面是a.do(假设你后台是java)那么请求地址是这样的a.do?par='123'par2='456'这个请求传递的参数就par和par2他俩的值分别为123，456

golang echo(二)---请求与响应

上一章节介绍了使用echo启动一个http服务器并提供一个简单的GET接口，这一章对请求与响应做一下详细的讲解。

了解请求与响应之前首先要知道ehco框架提供了一个Context接口，Context 表示当前 HTTP 请求的上下文，我们需要知道的是Context的实现结构体context，context中包含了请求(request)、响应(response)以及参数等结构体，context是一个内部结构体，但是对外提供了访问的方法，我们可以在开发中使用context提供的方法做很多事情，比如获取请求路径、客户端ip、请求参数等等。

request是包含了当前请求信息的结构体，我们从中可以获取到前后端约定好的参数来作出相应的业务逻辑，这下面开始模拟请求

首先模拟一个添加用户的POST请求，这里使用了c.bind()这个方法，这个方法起到的作用是把表单参数或者JSON参数绑定至对应的结构体(这里必须是指针类型)，字段需要一一对应，也就是说前端需要传递的表单或JSON参数名为name、age、gender才能绑定到结构体中。

接下来模拟一个GET请求用来获取用户信息

response是包含了返回信息的结构体，echo提供了多种类型的返回结果

上面编写了处理请求的handler，这里介绍一下如何把handler注册到路由中，这里对应的就是上面handler。

golang net/http包 http请求的字节码读取与解析。

先配置Header最长读取时间、req最长读取时间、req最大读取长度默认6M。

RFC7230禁止\r\n参数，Url中只允许包含英文字母（a-zA-Z）、数字（0-9）、-_.~4个特殊字符以及所有保留字符。但go net/http包放宽了这个要求。

先构建newTextprotoReader，由于缓冲区是对象复用的，用完后要defer put。共完以以下解析任务：

TextprotoReader数据结构，将字节码Reader转成文本Reader。

第一步，从第一行解析出method uri prototype。

第二步解析URL。url.URL数据结构：

解析Scheme，协议前缀（小写）。有查询参数?，则配置url.ForceQuery url.RawQuery。有认证信息///...//，则解析url.User url.Host。最后配置url.Path和url.RawPath，如果Path==RawPath，则RawPath=""。

第三步解析MIMEHeader。

第四步readTransfer。重新配置如下参数：RequestMethod ProtoMajor ProtoMinor Header Trailer ContentLength Close。对于Body，如果encodings支持chunked，读取流用chunkedReader包裹。默认情况用LimitedReader，无body赋空的struct{}。

以下情况返回非空err，示得到正确的请求：

最后配置req.ctx req.RemoteAddr req.TLS body.doEarlyClose = true。

构建Response:

其中closeNotifyCh必须在构建时初始化，没有content所以先置contentLength为-1。

配置w.cw并被w.w包裹。w.cw缓冲默认大小2M。

获取Request可能出现如下错误：

先上响应数据结构：

response字段可以分类为：大对象、缓冲、KV对或bool型的状态参数。

大对象有：

状态字段：

chunkWriter数据结构：

chunkWriter包裹了Response，功能之一是完成Header设置，包括Content-Type Content-Length chunk-header。bufio.Writer是chunkWriter是缓冲包裹。

handler将响应写入到response.w。

调用w.w.Flush()将w写入到cw，注意到Flush()操作，如果未刷空缓存并报错，触发拷贝操作。报错不会退回已写出的数据。

进而调用cw.Write()，根据cw.chunking参数。

putBufioWriter(w.w)清空resp.w缓冲，如果池化放回sync.pool。

根据chunkWriter的定义，w.cw.close()负责cw的结束工作：写入换行符和resp.trailers数据。

最后刷新TCP缓冲w.conn.bufw.Flush()，完成响应包发送。并正确关闭request。

golang jwt鉴权分析

技术栈 gin+jwt

鉴权流程：

调用token生成方法GenerateToken生成token, 请求api时带上token参数即可

token计算逻辑：

总结：md5加密账号和密码参数，根据账号密码私钥过期时间和jwt header 分别计算hash256值，将值用.符号连接，再进行hash,结果就是token值

api 验证token:

Golang 中更好的错误处理：理论和实践技巧

云和安全管理服务专家新钛云服 张春翻译

这种方法有几个缺点。首先，它可以对程序员隐藏错误处理路径，特别是在捕获异常不是强制性的情况下，例如在 Python 中。即使在具有必须处理的 Java 风格的检查异常的语言中，如果在与原始调用不同的级别上处理错误，也并不总是很明显错误是从哪里引发的。

我们都见过长长的代码块包装在一个 try-catch 块中。在这种情况下，catch 块实际上充当 goto 语句，这通常被认为是有害的（奇怪的是，C 中的关键字被认为可以接受的少数用例之一是错误后清理，因为该语言没有 Golang- 样式延迟语句）。

如果你确实从源头捕获异常，你会得到一个不太优雅的 Go 错误模式版本。这可能会解决混淆代码的问题，但会遇到另一个问题：性能。在诸如 Java 之类的语言中，抛出异常可能比函数的常规返回慢数百倍。

Java 中最大的性能成本是由打印异常的堆栈跟踪造成的，这是昂贵的，因为运行的程序必须检查编译它的源代码 。仅仅进入一个 try 块也不是空闲的，因为需要保存 CPU 内存寄存器的先前状态，因为它们可能需要在抛出异常的情况下恢复。

如果您将异常视为通常不会发生的异常情况，那么异常的缺点并不重要。这可能是传统的单体应用程序的情况，其中大部分代码库不必进行网络调用——一个操作格式良好的数据的函数不太可能遇到错误（除了错误的情况）。一旦您在代码中添加 I/O，无错误代码的梦想就会破灭：您可以忽略错误，但不能假装它们不存在！

try {

doSometing()

} catch (IOException e) {

// ignore it

}

与大多数其他编程语言不同，Golang 接受错误是不可避免的。 如果在单体架构时代还不是这样，那么在今天的模块化后端服务中，服务通常和外部 API 调用、数据库读取和写入以及与其他服务通信 。

以上所有方法都可能失败，解析或验证从它们接收到的数据（通常在无模式 JSON 中）也可能失败。Golang 使可以从这些调用返回的错误显式化，与普通返回值的等级相同。从函数调用返回多个值的能力支持这一点，这在大多数语言中通常是不可能的。Golang 的错误处理系统不仅仅是一种语言怪癖，它是一种将错误视为替代返回值的完全不同的方式！

重复 if err != nil

对 Go 错误处理的一个常见批评是被迫重复以下代码块：

res, err := doSomething()

if err != nil {

// Handle error

}

对于新用户来说，这可能会觉得没用而且浪费行数：在其他语言中需要 3 行的函数很可能会增长到 12 行 ：

这么多行代码！这么低效！如果您认为上述内容不优雅或浪费代码，您可能忽略了我们检查代码中的错误的全部原因：我们需要能够以不同的方式处理它们！对 API 或数据库的调用可能会被重试。

有时事件的顺序很重要：调用外部 API 之前发生的错误可能不是什么大问题（因为数据从未通过发送），而 API 调用和写入本地数据库之间的错误可能需要立即注意，因为 这可能意味着系统最终处于不一致的状态。即使我们只想将错误传播给调用者，我们也可能希望用失败的解释来包装它们，或者为每个错误返回一个自定义错误类型。

并非所有错误都是相同的，并且向调用者返回适当的错误是 API 设计的重要部分，无论是对于内部包还是 REST API 。

不必担心在你的代码中重复 if err != nil ——这就是 Go 中的代码应该看起来的样子。

自定义错误类型和错误包装

从导出的方法返回错误时，请考虑指定自定义错误类型，而不是单独使用错误字符串。字符串在意外代码中是可以的，但在导出的函数中，它们成为函数公共 API 的一部分。更改错误字符串将是一项重大更改——如果没有明确的错误类型，需要检查返回错误类型的单元测试将不得不依赖原始字符串值！事实上，基于字符串的错误也使得在私有方法中测试不同的错误案例变得困难，因此您也应该考虑在包中使用它们。回到错误与异常的争论，返回错误也使代码比抛出异常更容易测试，因为错误只是要检查的返回值。不需要测试框架或在测试中捕获异常 。

可以在 database/sql 包中找到简单自定义错误类型的一个很好的示例。它定义了一个导出常量列表，表示包可以返回的错误类型，最著名的是 sql.ErrNoRows。虽然从 API 设计的角度来看，这种特定的错误类型有点问题（您可能会争辩说 API 应该返回一个空结构而不是错误），但任何需要检查空行的应用程序都可以导入该常量并在代码中使用它不必担心错误消息本身会改变和破坏代码。

对于更复杂的错误处理，您可以通过实现返回错误字符串的 Error() 方法来定义自定义错误类型。自定义错误可以包括元数据，例如错误代码或原始请求参数。如果您想表示错误类别，它们很有用。DigitalOcean 的本教程展示了如何使用自定义错误类型来表示可以重试的一类临时错误。

通常，错误会通过将低级错误与更高级别的解释包装起来，从而在程序的调用堆栈中传播。例如，数据库错误可能会以下列格式记录在 API 调用处理程序中：调用 CreateUser 端点时出错：查询数据库时出错：pq：检测到死锁。这很有用，因为它可以帮助我们跟踪错误在系统中传播的过程，向我们展示根本原因（数据库事务引擎中的死锁）以及它对更广泛系统的影响（调用者无法创建新用户）。

自 Go 1.13 以来，此模式具有特殊的语言支持，并带有错误包装。通过在创建字符串错误时使用 %w 动词，可以使用 Unwrap() 方法访问底层错误。除了比较错误相等性的函数 errors.Is() 和 errors.As() 外，程序还可以获取包装错误的原始类型或标识。这在某些情况下可能很有用，尽管我认为在确定如何处理所述错误时最好使用顶级错误的类型。

Panics

不要 panic()！长时间运行的应用程序应该优雅地处理错误而不是panic。即使在无法恢复的情况下（例如在启动时验证配置），最好记录一个错误并优雅地退出。panic比错误消息更难诊断，并且可能会跳过被推迟的重要关闭代码。

Logging

我还想简要介绍一下日志记录，因为它是处理错误的关键部分。通常你能做的最好的事情就是记录收到的错误并继续下一个请求。

除非您正在构建简单的命令行工具或个人项目，否则您的应用程序应该使用结构化的日志库，该库可以为日志添加时间戳，并提供对日志级别的控制。最后一部分特别重要，因为它将允许您突出显示应用程序记录的所有错误和警告。通过帮助将它们与信息级日志分开，这将为您节省无数时间。

微服务架构还应该在日志行中包含服务的名称以及机器实例的名称。默认情况下记录这些时，程序代码不必担心包含它们。您也可以在日志的结构化部分中记录其他字段，例如收到的错误（如果您不想将其嵌入日志消息本身）或有问题的请求或响应。只需确保您的日志没有泄露任何敏感数据，例如密码、API 密钥或用户的个人数据！

对于日志库，我过去使用过 logrus 和 zerolog，但您也可以选择其他结构化日志库。如果您想了解更多信息，互联网上有许多关于如何使用这些的指南。如果您将应用程序部署到云中，您可能需要日志库上的适配器来根据您的云平台的日志 API 格式化日志 - 没有它，云平台可能无法检测到日志级别等某些功能。

如果您在应用程序中使用调试级别日志（默认情况下通常不记录），请确保您的应用程序可以轻松更改日志级别，而无需更改代码。更改日志级别还可以暂时使信息级别甚至警告级别的日志静音，以防它们突然变得过于嘈杂并开始淹没错误。您可以使用在启动时检查以设置日志级别的环境变量来实现这一点。

原文：