日常收集的题

# 一. 基础语法

# 1 = 和 := 的区别？

var a int
a = 10
// 等价于
a := 10

在 HTML 和各种 API 格式的上下文中，超媒体链接已经变成 Web 越来越重要的一部分。然而遗憾的是，没有一种通用单一的超媒体格式，也没有一种通用的方式来表示链接间的格式。 该规范旨在为 PHP 开发人员提供一种简单的、通用的方式来表示一个独立于所使用的序列化格式的超媒体链接。 这反过来又允许系统将超媒体链接的响应序列化为一种或多种有线格式，而不依赖于决定这些链接应该是什么的过程。

本文中的 必须，不得，需要，应，不应，应该，不应该，推荐，可以 和 可选 等能愿动词按照 RFC 2119 中的描述进行解释。

本文中的 必须，不得，需要，应，不应，应该，不应该，推荐，可以 和 可选 等能愿动词按照 RFC 2119 中的描述进行解释。

本文描述了依赖注入容器的通用接口。

设定 ContainerInterface 的目的是为了标准化框架或类库如何使用容器来获取对象和参数（本文其它部分称之为 实体 ）。

本文中的 必须，不得，需要，应，不应，应该，不应该，推荐，可以 和 可选 等能愿动词按照 RFC 2119 中的描述进行解释。

本文中关键字 implementor 被看作某些在依赖注入相关的框架或类库中实现了 ContainerInterface 接口。使用依赖注入容器（DIC）的用户被看作 user 。

此文档描述了 RFC 7230 和RFC 7231 HTTP 消息传递的接口，还有 RFC 3986 里对 HTTP 消息的 URIs 使用。

HTTP 消息是 Web 技术发展的基础。浏览器或 HTTP 客户端如 curl 生成发送 HTTP 请求消息到 Web 服务器，Web 服务器响应 HTTP 请求。服务端的代码接受 HTTP 请求消息后返回 HTTP 响应消息。

通常 HTTP 消息对于终端用户来说是不可见的，但是作为 Web 开发者，我们需要知道 HTTP 机制，如何发起、构建、取用还有操纵 HTTP 消息，知道这些原理，以助我们更好的完成开发任务，无论这个任务是发起一个 HTTP 请求，或者处理传入的请求。

缓存是提升应用性能的常用手段，为框架中最通用的功能，每个框架也都推出专属的、功能多样的缓存库。这些差别使得开发人员不得不学习多种系统，而很多可能是他们并不需要的功能。此外，缓存库的开发者同样面临着一个窘境，是只支持有限数量的几个框架还是创建一堆庞大的适配器类。

一个通用的缓存系统接口可以解决掉这些问题。库和框架的开发人员能够知道缓存系统会按照他们所预期的方式工作，缓存系统的开发人员只需要实现单一的接口，而不用去开发各种各样的适配器。

本文中的 必须，不得，需要，应，不应，应该，不应该，推荐，可以 和 可选 等能愿动词按照 RFC 2119 中的描述进行解释。

本文制定了日志类库的通用接口规范。

本规范的主要目的，是为了让日志类库以简单通用的方式，通过接收一个 Psr\Log\LoggerInterface 对象，来记录日志信息。 框架以及 CMS 内容管理系统如有需要，可以 对此接口进行扩展，但需遵循本规范，

这才能保证在使用第三方的类库文件时，日志接口仍能正常对接。 本文中的 必须，不得，需要，应，不应，应该，不应该，推荐，可以 和 可选 等能愿动词按照 RFC 2119 中的描述进行解释。

本文档中的 implementor 一词应理解为在日志的库中实现  LoggerInterface  的人。记录器的调用者称为 user。

本篇规范是 PSR-1 基本代码规范的继承与扩展。

本规范希望通过制定一系列规范化 PHP 代码的规则，以减少在浏览不同作者的代码时，因代码风格的不同而造成不便。

当多名程序员在多个项目中合作时，就需要一个共同的编码规范， 而本文中的风格规范源自于多个不同项目代码风格的共同特性， 因此，本规范的价值在于我们都遵循这个编码风格，而不是在于它本身。

本文中的 必须，不得，需要，应，不应，应该，不应该，推荐，可以 和 可选 等能愿动词按照 RFC 2119 中的描述进行解释。

本篇规范制定了代码基本元素的相关标准，以确保共享的 PHP 代码间具有较高程度的技术互通性。

本文中的 必须，不得，需要，应，不应，应该，不应该，推荐，可以 和 可选 等能愿动词按照 RFC 2119 中的描述进行解释。