基于 Composer 管理的 PHP 项目版本号从 x.x.x 变为 x.x 形式的影响

在使用 Composer 管理PHP项目的依赖时,版本号的变化(从 x.x.x 形式变成 x.x 形式)可能会影响依赖解析的方式。通常,版本号遵循语义化版本控制(Semantic Versioning, SemVer)规范,该规范定义了版本号的格式为 MAJOR.MINOR.PATCH,其中每一部分都有特定的意义:

  • MAJOR 版本在做出不兼容的 API 修改时增加。
  • MINOR 版本在功能的向后兼容补充时增加。
  • PATCH 版本在向后兼容的 bug 修复时增加。

如果你的项目的版本号从 x.x.x 变成了 x.x 形式,这可能意味着:

依赖声明的模糊性增加:当你使用 x.x.x 来声明依赖时,通常是指定了一个非常具体的版本范围。例如,1.2.3 只匹配 1.2.3 这个版本。而如果你使用 x.x 来声明依赖,如 1.2,那么这通常会被解释为 1.2.x,即 1.2.0 及其之后的所有小版本(直到下一个 MINOR 版本发布),这样就增加了匹配的版本范围。

潜在的向后不兼容风险:如果依赖的版本号由 x.x.x 变更为 x.x 形式,并且没有明确的版本约束,那么可能会引入一些意外的更新,这些更新可能包含了向后不兼容的更改。

Composer 的解析行为:Composer 会根据你提供的版本约束来解析依赖关系。如果版本号格式变化导致约束变得更宽泛,Composer 可能会选择不同版本的包,从而影响项目的稳定性。

总结来说,从 x.x.x 到 x.x 的版本号变化可能会影响你的项目对具体版本的依赖控制。如果你希望保持对特定版本的控制,最好继续使用完整的 MAJOR.MINOR.PATCH 格式;否则,如果接受更广泛的版本更新,则可以使用 x.x 形式。但是需要注意潜在的风险,并确保在更新依赖之前进行充分的测试。

MiniFramework 2.10 已经发布,超轻量级的国产 PHP 框架

MiniFramework 2.10 已经发布,超轻量级的国产 PHP 框架

此版本更新内容包括:

版本变化

  • 新增常量 ERROR_PAGE,默认值为空,用于声明自定义错误页面。
  • 新增支持输出自定义错误页的特性。
  • 新增自定义错误页的示例代码。
  • 新增 Mini\Base\Response 类的 charset() 方法,用于在响应头中自定义字符编码。
  • 新增 Mini\Base\Rest 类的 response() 和 type() 方法,对输出进行统一封装。
  • 调整错误信息输出方式,当启用 REST 模式对 API 接口请求遇到异常时,将以 JSON 格式输出错误信息。
  • 改进 Mini\Base\App 类的 dispatch() 方法,支持传入参数带入 Action 中。
  • 改进 Mini\Base\App 类,增加名为 isApi 属性,用于判断当前请求是否为 REST 接口。
  • 改进 Mini\Base\Action 类的 forward() 方法,支持跳转时传递参数。
  • 改进 Mini\Base\Rest 类,在构造阶段即将默认的 json 方式传递给 Response 对象。
  • 改进 Mini\Base\Exception 类,在 CLI 模式下运行时默认输出错误信息。
  • 改进 Mini\Base\Loader 类,在自动加载过程遇到文件不存在时不主动抛出错误。
  • 改进 Mini\Base\Layout 类的 setLayout() 方法,参数允许留空或传入 null 以清除历史布局设置。
  • 调整 Mini\Base\Layout 类,取消单例模式,改为常规的实例化对象方式。
  • 改进 Mini\Base\Action 类的 forward() 方法,跳转前默认清除历史的布局设置。
  • 改进 Mini\Base\View 类的属性声明方式,以兼容 PHP 7.2 和 7.3 版本。
  • 改进框架默认的报错输出格式,优化阅读体验。
  • 修复 Mini\Cache\File 类的 set() 和 del() 两个方法中写入和删除文件的Bug。
  • 修复配置自定义路由与 CLI 模式运行时出现的路由冲突问题。

升级说明

  • 兼容 PHP 最低版本为 7.2.0,PHP 8.3 已测试可正常运行。
  • 当前版本向前兼容至 2.4.0 版本,使用 2.4.0 及后续版本的开发者可直接升级至 2.10.0 版本。
  • 文档已同步更新,地址:http://www.miniframework.com/docv2/guide/

详情查看:https://gitee.com/jasonwei/miniframework/releases/2.10.0

使用 ArkUI 开发鸿蒙 HarmonyOS 原生应用界面交互 实现 Stepper 组件内部滚动浏览内容

在基于华为鸿蒙 HarmonyOS 的 ArkUI 搭建界面交互时,使用 Stepper 组件时,让其内部的内容在超出容器可视范围时,能够正常进行滚动浏览,可以使用 Scroll 可滚动的容器组件。

由于 Stepper 组件内部只允许嵌入 StepperItem 组件,所以我们要把 Scroll 放入 StepperItem 内部,下面给出代码示例:

阅读更多

解决使用 aws-sdk-php 向天翼云对象存储请求 STS 临时凭证报错的问题

本人近期在使用天翼云部署一个 PHP 开发的系统时,在使用 aws-sdk-php 向天翼云对象存储发起STS临时凭证请求时,遇到了如下报错:

Fatal error: Uncaught Aws\Api\Parser\Exception\ParserException: Invalid timestamp value passed to DateTimeResult::fromTimestamp in /data/htdocs/myapp/vendor/aws/aws-sdk-php/src/Api/DateTimeResult.php:100

经过对 aws-sdk-php 源代码进行分析后,决定自己动手进行一些改造,让 aws-sdk-php 兼容天翼云,具体方法如下:

阅读更多

详解用 MiniFramework 框架实现对 GET 或 POST 请求参数进行签名校验的方法

在一些特殊场景下,我们可能希望对于 GET 或 POST 进入到接口的数据进行签名和有效期的校验,例如 APP 请求后端接口的场景,我们通常需要考虑两个问题:

问题1:如何避免攻击者在捕获到接口请求后,自行构造请求参数,向接口发送请求,而不通过 APP 的正常界面进行操作。

问题2:在接口请求不可避免能被捕获的情况下,如何确保每一次请求能够过期,不被反复的利用,例如投票刷票的问题。

基于上面两个问题,我们在设计接口时,就需要通过给请求参数进行签名的方式来对数据来源和有效期进行校验。下面将以 MiniFramework 框架为例,演示如何通过 MiniFramework 框架来实现对请求参数进行签名和签名校验的方法。

阅读更多

MiniFramework 2.9.0 已经发布,超轻量级的 PHP 框架

MiniFramework 2.9.0 已经发布,超轻量级的 PHP 框架

此版本更新内容包括:

版本变化

  • 新增 Mini\Base\Header 类,用于处理 Request 和 Response 的 Header 信息。
  • 新增 Mini\Base\Response 类,用于响应客户端,控制请求结果的输出。
  • 新增 Mini\Base\App::setAction () 方法,用于设置动作。
  • 新增 Mini\Base\App::setController () 方法,用于设置控制器。
  • 新增 Mini\Base\Action::forward () 替代原 _forward () 方法,旧方法暂时保留,新旧两个方法功能完全一致。
  • 新增 Mini\Security\Sign 类的 setEncryptType () 方法,用于指定加密方式。
  • 改进 Controller 和 Action 的设置由 Mini\Base\App 类负责处理。
  • 改进在部分核心类库中用 Mini\Base\Response 替代 Mini\Base\Http 以规范响应输出。
  • 改进并优化框架异常报错的特性。
  • 修复 Action 中使用 $this->_forward () 跳转相同的 Action 时出现死循环的 Bug。
  • 修复 Mini\Base\Http 在被继承的场景中可能出现的实例获取 Bug。
  • 修复全局函数 isTimestamp () 校验时间戳的 Bug。

升级说明

  • 兼容 PHP 最低版本为 7.2.0,PHP 8.0.0 已测试可正常运行。
  • 当前版本向前兼容至 2.4.0 版本,使用 2.4.0 及后续版本的开发者可直接升级至 2.9.0 版本。
  • 文档已同步更新,地址:http://www.miniframework.com/docv2/guide/

详情查看:https://gitee.com/jasonwei/miniframework/releases/2.9.0

转载:Redis 的 KEYS 命令引起 RDS 数据库雪崩

最近的互联网线上事故发生比较频繁,9月19日网上爆料出顺丰近期发生了一起线上删库事件,在这里就不介绍了。

在这里讲述一下最近发生在我公司的事故,以及如何避免,并且如何处理优化。 该宕机的直接原因是使用 Redis 的 keys * 命令引起的,一共造成了某个服务化项目的两次宕机。

间接原因还有很多,技术跟不上业务的发展,由每日百万量到千万级是一个大的跨进,公司对于系统优化的处理优先级不高,技术开发人手的短缺。
第一次宕机

2018年9月13日的某个点,公司某服务化项目的 RDS 实例连接飙升,CPU 升到 100%,拒绝了其他应用的所有请求服务。

整个过程如下:

阅读更多