分类： Web应用开发
-
本文针对当前 Excel 导出进度由前端独立显示且未受后端控制的问题，制定了按实际导出进度展示的调整规则。实施后，后端处理过程分为四个阶段：作业排队时进度保持 0%；实际写入数据时按每 1000 行增加 9.9% 直至 99%；完成格式处理及文件上传后显示 100%；最后前端获取下载链接时不再显示进度。该方案通过细化后端处理步骤实现了进度的准确同步。
-
本文针对 Laravel 9 中存在两组时间字段的验证需求，说明了如何确保 shipping_at_gmt_start、shipping_at_gmt_end 与 operated_at_gmt_start、operated_at_gmt_end 这 4 个字段中必须存在完整的一组。文章介绍了利用 required_without 规则的实现逻辑，即当一组字段的部分或全部缺失时，强制另一组字段必填，从而在两组字段间实现互斥必填的验证效果。
-
本文探讨了在 Laravel 9 中验证两个时间字段跨度不可超过 3 个月的实现方法。文章介绍了使用闭包结合 Carbon 自定义验证规则，将起始时间加上 3 个月后与结束时间进行比较，并处理了起始字段不存在时避免报错的逻辑。最终通过具体的时间参数测试，验证了该规则在 2024 年闰年场景下能够正确判断时间跨度的合规性。
-
针对 MySQL 8 中 IN 条件用于多个字段时查询结果为空的问题，文章记录了在 Laravel 9 中使用原生查询遇到的语法错误与列数违规报错。尽管报错 SQL 手动执行成功，但程序运行异常，最终决定放弃该 SQL 写法，调整为另一种 SQL 格式，解决了报错并使查询结果符合预期。
-
本文分析了同一条count(*)查询SQL在Navicat中仅需3秒，而在Laravel 9中执行却耗时60秒的性能差异问题。通过在容器Tinker命令行及程序中执行原生SQL进行验证，排除数据库连接因素，确认耗时仅3秒左右。最终排查发现性能瓶颈位于Laravel框架底层Builder.php的runPaginationCountQuery方法。由于暂不便修改框架底层实现，决定将查询条件改为使用where shipping_type in (1, 2)来规避问题，使执行时长降至3秒左右，符合预期。
-
针对 Laravel 查询生成器中检测 SQL 是否已包含 where 条件的需求，文章参考了 MySQL 8.0 查询优化案例及相关技术讨论，介绍了如何在缺少 where 子句时自动添加条件以符合查询预期。文章详细展示了具体的实现方式及最终生成的 SQL 语句，确认了该方案能有效识别并处理查询条件，解决了业务开发中的逻辑判断问题。
-
针对 MySQL 8.0 中接口响应超时的问题，分析发现 count(*) SQL 在千万级数据表下耗时 54 秒。通过在查询中添加 shipping_type 索引条件，耗时降至 3 秒。为保持 SQL 结构统一，最终采用添加 WHERE id > 0 的方式优化，查询耗时 4 秒，达到了预期的性能提升效果。
-
在 Laravel 9 中，为确保批量覆盖写入时 logistics_freight_no 的唯一性，需先清空指定记录再重新写入。由于不得不将请求参数 return_order_id 传递给 ignore 方法以忽略当前 ID，为防止 SQL 注入风险，提前验证其为 Eloquent 模型实例 ID 并强制转换为 int 类型。测试结果显示，指定 ID 下重复校验通过，非指定 ID 校验失败，最终执行的 SQL 符合预期。
-
针对 Laravel 9 中使用 spatie/laravel-query-builder 查询关联表字段时，初始实现因始终执行 join 语句导致不查询关联字段时报错的问题，文章介绍了调整实现的方法。通过在准备好 new Request 实例后再判断是否添加 join 语句，最终实现了 SQL 语句按需关联其他表，解决了报错并符合预期逻辑。
-
在 Laravel 9 开发中遇到 Call to undefined method Illuminate\Http\Resources\MissingValue::isEmpty() 报错。经排查，该问题出现在 API 资源类的 $this->whenLoaded() 方法调用中。通过打印调试发现，错误源于在模型关联未被加载时的返回值处理不当。重新修改代码实现逻辑后，问题得到解决，不再报错。