Joyber 发布的文章

在 Git 中，CRLF（Carriage Return + Line Feed） 是 Windows 系统的换行符，而 Linux/macOS 用 LF（Line Feed）。Git 默认会自动转换换行符（Windows 下拉取时 LF→CRLF，提交时 CRLF→LF），若想禁用这种自动转换（即 “不设置 CRLF”），核心是通过 Git 配置关闭换行符自动处理，具体操作如下：
一、核心配置：禁用 CRLF 自动转换
通过 core.autocrlf 配置控制换行符转换，禁用需设置为 false，支持全局配置（所有仓库）或局部配置（当前仓库）。

  1. 全局配置（推荐，所有 Git 仓库生效）
    打开终端 / 命令行，执行：

    git config --global core.autocrlf false

  2. 局部配置（仅当前仓库生效）
    进入项目的 Git 仓库根目录，执行：

    git config core.autocrlf false

    配置说明：
    core.autocrlf false：Git 不做任何换行符转换，工作区文件的换行符完全由你本地编辑器 / 系统决定（Windows 保留 CRLF，Linux/macOS 保留 LF）；
    对比默认值 true（Windows 下自动转换）和 input（仅提交时 CRLF→LF，拉取不转换），false 是彻底禁用转换。
    二、补充配置：避免 Git 标记文件为 “已修改”（可选）
    若禁用转换后，Git 仍误判文件因换行符变化为 “已修改”，需配置 core.safecrlf 关闭换行符检查：

    # 全局禁用换行符检查（推荐）
git config --global core.safecrlf false
core.safecrlf

    说明：
    true（默认）：提交时若存在混合换行符，Git 会报错阻止提交；
    false：关闭检查，允许混合换行符提交

检查并会阻止提交

git config --global core.autocrlf true
git config --global --unset core.safecrlf

仅恢复 core.autocrlf 默认值

Windows 系统中 Git 默认core.autocrlf为true，若之前设为false，执行以下命令单独恢复该配置：

git config --global core.autocrlf true

1. 克隆主仓库时直接拉取子模块（首次拉取代码时，默认会拉取子模块，推荐）

# --recursive 递归拉取所有子模块
git clone --recursive git@gitcode.com:xxx/supo-admin.git

2. 已克隆主仓库，后续同步子模块

# 初始化子模块（若未初始化）
git submodule init

# 拉取子模块代码并更新到最新版本
git submodule update --remote

3. 常用子模块维护命令

# 3-1. 更新子模块到远程最新版本
# 只更新 admin-web 子模块
git submodule update --remote admin-web

# 或更新所有子模块
git submodule update --remote

# 3-2. 进入子模块操作（如提交子模块代码）
# 进入子模块目录
cd admin-web
# 拉取子模块的远程更新
git pull origin 子模块分支名

git add .
git commit -m "fix: 子模块修复bug"

# 推送子模块的代码到远程
git push origin master

4. 移除子模块（如需删除）

# 4-1. 解除主仓库对子模块的跟踪
git submodule deinit -f admin-web

# 4-2. 删除子模块的本地目录
rm -rf admin-web

# 4-3. 删除主仓库中 .git 目录下的子模块配置
rm -rf .git/modules/admin-web

# 4-4. 从 .gitmodules 中删除该子模块的配置（或手动编辑 .gitmodules 删除对应段落）
git rm --cached admin-web

# 4-5. 提交删除操作
git commit -m "feat: 移除 admin-web 子模块"
git push

5. 添加子模块

git submodule https://gitcode.com/xxx/merchant-web.git merchant-web

恢复到项目 未执行 git submodule init 的状态，后续可再次拉子模块代码

要让 Git 子模块目录恢复到“未初始化/未拉取代码”的状态（和执行 git submodule init 前一致，仅保留子模块配置，删除本地代码），核心是 保留子模块的 Git 配置（.gitmodules 和 .git/config 中的记录），但删除子模块的本地代码目录和 Git 跟踪文件。以下是具体步骤：

核心逻辑

目标状态：

  • 保留 .gitmodules 文件（子模块配置记录）；
  • 保留 .git/config 中可能存在的子模块配置（可选，若之前执行过 init）；
  • 删除子模块的本地代码目录（如 submodule-dir/）；
  • 删除 Git 对其子模块的跟踪文件（.git/modules/[子模块名]）。

具体操作步骤

假设你的子模块目录名为 submodule-dir（替换为实际子模块目录名）：

1. 先确保子模块目录无未提交的修改（可选，避免数据丢失）

如果子模块目录中有自己的修改，先备份或提交（否则删除后会丢失）：

# 进入子模块目录查看状态
cd submodule-dir
git status
# 若有未提交文件，可备份或提交（根据需求选择）

2. 删除子模块的本地代码目录

直接删除子模块的物理目录（这是“看起来没拉取代码”的核心）：

# 回到项目根目录
cd ..
# 删除子模块目录（本地代码全部删除）
rm -rf submodule-dir/

3. 删除 Git 对其子模块的跟踪文件

Git 会将子模块的版本信息、配置等存储在 .git/modules/[子模块名] 目录中，必须删除才能彻底恢复到“未初始化”状态：

# 删除 Git 跟踪的子模块元数据（替换为实际子模块名）
rm -rf .git/modules/submodule-dir/

4. （可选）保留子模块配置（关键！和 git submodule init 前一致）

如果想保留 .gitmodules 中的配置（后续可重新执行 git submodule init && git submodule update 拉取代码），无需删除 .gitmodules 文件。

若之前执行过 git submodule init，.git/config 中会有子模块的配置记录，若想完全恢复到“从未 init”的状态，可删除该记录：

# 取消 .git/config 中对子模块的配置（可选，不删也不影响“无代码”状态）
git config --unset-all submodule.submodule-dir

最终效果验证

操作完成后，项目状态如下：

  • 子模块目录 submodule-dir/ 不存在（或为空）；
  • .gitmodules 文件保留（子模块配置还在）；
  • 执行 git submodule status 会显示类似 -xxxxxx submodule-dir (未初始化) 的提示（说明子模块未拉取代码）；

  • 后续若需重新拉取子模块，只需执行：

    git submodule init  # 初始化（读取 .gitmodules 配置）
git submodule update  # 拉取子模块代码

简化命令（一键操作，替换为实际子模块名）

# 替换 submodule-dir 为你的子模块目录名
SUBMODULE_NAME="submodule-dir" && rm -rf $SUBMODULE_NAME && rm -rf .git/modules/$SUBMODULE_NAME && git config --unset-all submodule.$SUBMODULE_NAME

总结

通过“删除子模块目录 + 删除 Git 跟踪元数据”，即可让子模块恢复到“未拉取代码”的初始状态，和未执行 git submodule init/update 时完全一致，且保留了后续重新拉取的配置。

在 Yii2 中编写自定义类时，继承框架基础类的核心原则是：根据自定义类的功能场景，选择最贴合的「抽象基类/接口」或「功能基类」，避免盲目继承（如直接继承 yii\base\Object 已过时，Yii2.0.13+ 推荐 yii\base\BaseObject）。

以下按「功能场景分类」，整理常用的可继承基础类，附使用场景和代码示例，覆盖绝大多数开发需求：

一、核心基础类（所有自定义类的通用父类）

这类类是 Yii2 所有组件的根基，提供「属性访问、事件触发、依赖注入」等核心能力，适合所有需要框架核心特性的自定义类。

框架基础类核心功能适用场景代码示例
yii\base\BaseObject提供 __get()/__set()、hasProperty()、init() 等属性和初始化能力（Yii2.0.13+ 推荐）所有需要「属性访问、初始化逻辑」的自定义类php namespace app\components; use yii\base\BaseObject; class MyTool extends BaseObject { public $name; public function init() { parent::init(); // 初始化逻辑（如参数校验） if (empty($this->name)) { throw new \Exception('名称不能为空'); } } }
yii\base\Component继承 BaseObject，额外提供「事件机制、行为（Behavior）支持」需事件触发、行为扩展的类（如组件、服务）php namespace app\components; use yii\base\Component; class MyService extends Component { const EVENT_AFTER_DO = 'afterDo'; public function doSomething() { // 触发事件 $this->trigger(self::EVENT_AFTER_DO); } } // 使用时绑定事件 $service = new MyService(); $service->on(MyService::EVENT_AFTER_DO, function() { echo '执行后触发'; });
yii\base\Object旧版核心基类（Yii2.0.13 前），功能与 BaseObject 一致，已被弃用兼容旧版本代码（不推荐新增）-

二、数据模型类（处理数据验证、数据库交互）

若自定义类需「数据验证、数据库 CRUD」，优先继承以下模型基类，直接复用 Yii2 的数据处理能力。

框架基础类核心功能适用场景代码示例
yii\base\Model提供「属性验证、场景支持、错误信息管理」（无数据库交互）表单提交、接口参数验证（非数据库模型）php namespace app\models; use yii\base\Model; class LoginForm extends Model { public $username; public $password; public function rules() { return [ [['username', 'password'], 'required'], ['password', 'string', 'min' => 6], ]; } } // 使用时验证 $form = new LoginForm(['username' => 'test', 'password' => '123456']); if ($form->validate()) { // 验证通过 }
yii\db\ActiveRecord继承 Model，额外提供「数据库 CRUD、关联查询、属性映射」数据库表对应的模型（核心推荐）php namespace app\models; use yii\db\ActiveRecord; class User extends ActiveRecord { public static function tableName() { return 'user'; // 对应数据库表名 } } // 数据库操作 $user = User::findOne(1); $user->username = 'newName'; $user->save();
yii\db\BaseActiveRecordActiveRecord 的抽象基类，可用于自定义 ORM 逻辑（如非关系型数据库）扩展数据库驱动、自定义 ORM 时使用-
yii\base\DynamicModel动态模型，无需预先定义属性，适合临时数据验证（如单次接口参数）临时数据验证、动态表单（无需创建实体类）php $model = DynamicModel::validateData([ 'email' => 'test@example.com', 'age' => 20, ], [ ['email', 'email'], ['age', 'integer', 'min' => 18], ]); if ($model->hasErrors()) { // 处理错误 }

三、控制器/动作类（Web 接口/页面逻辑）

用于编写 Web 接口、页面渲染逻辑，继承后可直接复用「请求处理、响应输出、权限控制」等能力。

框架基础类核心功能适用场景代码示例
yii\web\ControllerWeb 应用核心控制器，提供「视图渲染、请求获取、响应处理、行为支持」普通 Web 页面、HTML 接口控制器php namespace app\controllers; use yii\web\Controller; class SiteController extends Controller { public function actionIndex() { // 渲染视图 return $this->render('index'); } }
yii\rest\Controller专为 RESTful 接口设计，提供「JSON 响应、HTTP 方法映射、接口权限」RESTful API 控制器（如前后端分离接口）php namespace app\controllers; use yii\rest\Controller; class ApiController extends Controller { public function actionUser($id) { return ['id' => $id, 'name' => 'test']; // 自动转为 JSON 响应 } }
yii\rest\ActiveController继承 rest\Controller，自动实现「CRUD 接口」（无需手动写增删改查）快速实现 RESTful CRUD 接口（如资源管理）php namespace app\controllers; use yii\rest\ActiveController; class UserController extends ActiveController { public $modelClass = 'app\models\User'; // 关联数据模型 } // 自动生成接口：GET /user（列表）、GET /user/1（详情）、POST /user（新增）
yii\console\Controller命令行控制器，用于编写定时任务、脚本（如数据迁移、批量处理）控制台命令、定时任务（如 yii xxx/xxx）php namespace app\commands; use yii\console\Controller; class TestController extends Controller { public function actionIndex() { echo '控制台命令执行成功'; } } // 执行：php yii test/index

四、过滤器/行为类（请求拦截、功能扩展）

用于「请求拦截、权限校验、日志记录、缓存控制」等横切逻辑，继承后可嵌入控制器/组件的生命周期。

框架基础类核心功能适用场景代码示例
yii\base\ActionFilter动作过滤器基类，提供 beforeAction()（动作执行前）、afterAction()（执行后）钩子接口权限校验、日志记录、请求频率限制php namespace app\filters; use yii\base\ActionFilter; class AuthFilter extends ActionFilter { public function beforeAction($action) { // 动作执行前校验 if (!Yii::$app->user->isGuest) { return true; } Yii::$app->response->statusCode = 401; return false; } } // 在控制器中使用 public function behaviors() { return [ 'auth' => ['class' => AuthFilter::class], ]; }
yii\filters\AccessControl内置权限过滤器，支持「角色权限、IP 白名单、HTTP 方法限制」快速实现权限控制（如仅管理员访问）php public function behaviors() { return [ 'access' => [ 'class' => \yii\filters\AccessControl::class, 'rules' => [ ['allow' => true, 'roles' => ['@'], // 仅登录用户允许 'actions' => ['index'], ], ], ], ]; }
yii\base\Behavior行为基类，用于给组件动态添加属性/方法（无侵入扩展）组件功能扩展（如给模型添加日志方法）php namespace app\behaviors; use yii\base\Behavior; use yii\db\ActiveRecord; class LogBehavior extends Behavior { public function events() { return [ ActiveRecord::EVENT_AFTER_INSERT => 'afterInsert', ]; } public function afterInsert($event) { // 模型新增后记录日志 Yii::info('新增数据：' . $event->sender->id); } } // 给模型添加行为 public function behaviors() { return ['log' => ['class' => LogBehavior::class]]; }

五、工具/辅助类（特定功能场景）

针对「缓存、日志、验证器、命令行」等特定场景，继承对应基类可复用框架内置能力。

框架基础类核心功能适用场景代码示例
yii\caching\Cache缓存抽象基类，提供 get()/set()/delete() 等缓存操作接口自定义缓存驱动（如 Redis 扩展、本地文件缓存）php namespace app\caching; use yii\caching\Cache; class MyCache extends Cache { protected function getValue($key) { // 自定义获取缓存逻辑 } protected function setValue($key, $value, $duration) { // 自定义设置缓存逻辑 } }
yii\log\Target日志目标基类，用于自定义日志存储方式（如写入数据库、第三方日志服务）扩展日志存储（如 ELK、阿里云日志）php namespace app\log; use yii\log\Target; class DbTarget extends Target { public function export() { $logs = $this->getLogs(); // 将日志写入数据库 foreach ($logs as $log) { Yii::$app->db->createCommand()->insert('sys_log', [ 'message' => $log[0], 'level' => $log[1], ])->execute(); } } }
yii\validators\Validator验证器基类，用于自定义数据验证规则（如手机号、身份证号校验）扩展验证规则（框架未提供的自定义校验）php namespace app\validators; use yii\validators\Validator; class PhoneValidator extends Validator { public function validateAttribute($model, $attribute) { $value = $model->$attribute; if (!preg_match('/^1[3-9]\d{9}$/', $value)) { $this->addError($model, $attribute, '手机号格式错误'); } } } // 在模型中使用 public function rules() { return [ ['phone', PhoneValidator::class], ]; }
yii\console\Action命令行动作基类，用于编写复杂命令行逻辑（拆分命令为多个动作）复杂控制台命令（如批量导入数据的子步骤）php namespace app\commands\actions; use yii\console\Action; class ImportAction extends Action { public function run($file) { // 执行导入逻辑 echo "从 {$file} 导入数据"; } } // 在命令行控制器中绑定 public function actions() { return [ 'import' => ImportAction::class, ]; } // 执行：php yii test/import --file=data.csv

六、继承原则与避坑要点

  1. 最小继承原则：不需要的功能不继承（如仅需属性验证 → 继承 Model，无需继承 ActiveRecord）；
  2. 优先接口/抽象类：框架提供的抽象基类（如 Cache、Validator）定义了标准接口，继承后需实现必填方法（如 Cache 的 getValue()）；
  3. 避免多层继承：Yii2 推荐「组合优于继承」，复杂功能优先用「行为（Behavior）」扩展，而非多层继承；
  4. 注意版本兼容性：BaseObject 是 Yii2.0.13+ 新增，若项目版本低于该版本，需用 Object；
  5. 初始化逻辑写在 init() 中：继承 BaseObject/Component 时，不要重写 __construct()，而是通过 init() 实现初始化（框架会自动调用）。

总结

选择继承的框架类，核心看「自定义类的功能场景」：

  • 数据验证 → yii\base\Model；
  • 数据库交互 → yii\db\ActiveRecord；
  • Web 接口 → yii\rest\Controller；
  • 请求拦截 → yii\base\ActionFilter；
  • 通用组件 → yii\base\Component（需事件/行为）或 yii\base\BaseObject（仅需属性/初始化）。

按场景选择合适的基类，可最大化复用框架能力，减少重复代码，同时保证代码符合 Yii2 的设计规范。

订单搜索优化方案

核心目标：解决订单搜索（多条件、大数据量）慢问题，兼顾「查询性能」「业务适配」「开发成本」，核心思路：索引优化+查询逻辑优化+存储/架构优化，按优先级逐步落地。

一、先做低成本高收益：索引优化（优先级最高）

订单搜索慢80%是索引缺失/不合理，优先针对性建索引，无代码侵入，见效最快。

  1. 核心搜索字段索引（必建）

订单搜索高频字段： order_no （订单号）、 user_id （用户ID）、 order_status （订单状态）、 create_time （创建时间），按「单字段索引+联合索引」组合设计：

  • 单字段索引： idx_order_no （订单号，精确匹配为主，如搜索某订单号）、 idx_user_id （用户ID，查用户所有订单）
  • 联合索引（覆盖高频多条件搜索，遵循「左前缀原则」）：
  •  idx_status_create （ order_status ,  create_time ）：适配「按状态+时间筛选」（如待发货+近7天）
  •  idx_user_status （ user_id ,  order_status ）：适配「按用户+状态筛选」（如用户A的待付款订单）
  •  idx_user_create （ user_id ,  create_time ）：适配「按用户+时间筛选」（如用户A近30天订单）
  • 索引语法（MySQL）：
    -- 单字段索引
    CREATE INDEX idx_order_no ON order(order_no);
    CREATE INDEX idx_user_id ON order(user_id);
    -- 联合索引
    CREATE INDEX idx_status_create ON order(order_status, create_time);
    CREATE INDEX idx_user_status ON order(user_id, order_status);
     
  1. 索引避坑要点
  • 不建冗余索引：如已有 idx_user_status_create （user_id,order_status,create_time），无需再建 idx_user_status 
  • 高基数字段放联合索引左前：如 user_id （基数高）比 order_status （基数低，仅待付/待发/完成等）优先
  • 避免过度索引：单表索引≤6个，过多会拖慢订单创建/更新速度

二、查询逻辑优化（开发成本低，见效快）

  1. 过滤条件优先用索引字段
  • 搜索时先通过「status/create_time/user_id」等索引字段缩小数据范围，再过滤非索引字段（如 consignee 收件人）
  • 反例：先查所有订单，再筛选收件人；正例：先按「待发+近7天」（索引字段）过滤，再匹配收件人
  1. 精准匹配优先，模糊匹配优化
  • 订单号搜索：用 = 精准匹配（走 idx_order_no 索引），避免 like %xxx% （索引失效）；若需前缀匹配（如订单号前6位），用 like 'xxx%' （可走索引）
  • 收件人/手机号搜索：
  • 手机号：存明文/脱敏后，用 like '138%' （前缀匹配，建 idx_consignee_mobile 索引）
  • 收件人：避免全模糊，可做「分词+冗余字段」（如 consignee_pinyin 存拼音首字母，搜“张三”匹配“ZS%”）
  1. 分页与字段裁剪

  • 分页防深页：用 create_time+id 游标分页（代替 limit 10000,20 ，深页时索引失效），示例：
    // 游标分页：上一页最后一条的create_time和id
    $query->where(['>', 'create_time', $lastCreateTime])

    ->orWhere(['=', 'create_time', $lastCreateTime])
->andWhere(['>', 'id', $lastId])
->limit(20);

     

  • 字段裁剪：只查需要的字段（避免 select * ），联合索引可覆盖查询（如 idx_user_status 覆盖 user_id,status,id ，无需回表查主表）
  1. 避免查询无效数据
  • 过滤已删除订单（ is_delete=0 ，可加进联合索引，如 idx_status_delete_create ）
  • 时间范围不超过90天：默认只查近90天订单，历史订单提供「按年月筛选」入口（缩小范围）
  1. 批量查询防N+1
  • 查订单时关联「用户/商品」，用Yii2 with() 预加载，避免循环查关联数据：
    Order::find()->with(['user', 'orderGoods'])->where(...); // 预加载，仅2次查询
     

三、中成本优化：存储与冗余设计

  1. 历史订单分表（订单量≥100万条必做）
  • 按时间分表：近3个月订单存在 order 主表，历史订单按「年月」分表（如 order_202501 ）
  • 分表策略：
  • 写入：新订单写主表，每月底定时将上月订单迁移到历史分表
  • 读取：近3个月查主表，历史订单查对应分表；跨表搜索用「分表聚合」（如UNION ALL，仅历史数据用）
  1. 冗余高频搜索字段
  • 非索引字段（如 consignee 收件人、 mobile 手机号）若高频搜索，可冗余到订单表（避免关联地址表）
  • 示例：订单表冗余 consignee （收件人）、 mobile （脱敏手机号），建 idx_consignee_mobile 索引，适配收件人/手机号前缀搜索
  1. 大字段拆分
  • 订单表中 order_desc （订单备注）、 ext_info （扩展信息）等大字段，拆分到 order_ext 表（一对一关联），减少主表数据量，提升查询速度

四、高成本高收益：架构层优化（订单量≥500万条）

  1. 引入ES（Elasticsearch）做全文检索
  • 适用场景：多字段混合搜索（如“用户A+待付款+近7天+收件人张三”）、全模糊搜索（如收件人“%三%”）
  • 实现方案：
  • 数据同步：订单创建/更新时，同步数据到ES索引（用MQ解耦，避免影响订单主流程）
  • 搜索查询：复杂搜索走ES，简单查询（订单号/用户ID）仍走MySQL，ES返回订单ID，再从MySQL查详情（ES+MySQL混合查询，兼顾速度与数据一致性）
  1. 读写分离
  • 订单创建/更新写主库，搜索查询读从库，分摊主库压力
  • 适配场景：QPS≥1000，主库压力大时，读从库可提升查询响应速度
  1. 热点数据缓存
  • 高频搜索数据（如用户近30天订单、热门状态订单）缓存到Redis，过期时间5-15分钟（根据订单更新频率调整）
  • 示例：缓存用户1001近30天订单，键 order:user:1001:30d ，值存订单ID列表，查询时先查缓存，无则查DB再回写缓存

五、落地优先级&效果预期

优化层级 具体方案 开发成本 性能提升 适用订单量
1级（必做） 核心索引优化+查询逻辑优化 低 50%-200% ＜100万
2级（推荐） 历史订单分表+字段冗余 中 200%-500% 100万-500万
3级（按需） ES全文检索+读写分离 高 500%+ ≥500万

六、监控与迭代

1. 监控慢查询：开启MySQL慢查询日志（阈值≥500ms），定期分析订单搜索慢SQL，针对性优化
2. 监控索引使用率：用 sys.schema_unused_indexes 查看未使用索引，及时删除冗余
3. 迭代优化：先落地1-2级方案，观察1-2周，若仍不满足需求，再推进ES等3级方案

按此方案落地，可解决大部分订单搜索慢问题，兼顾成本与效果，适配不同订单量规模的业务场景。

  1. 1
  2. ...
  3. 8
  4. 9
  5. 10
  6. 11
  7. 12
  8. 13
  9. 14
  10. ...
  11. 144