标签: PHP

  • 为什么越来越多的网站开始采用前后端分离?

    为什么越来越多的网站开始采用前后端分离?

    为什么越来越多的网站开始采用前后端分离?

    从传统的 PHP 网站,到如今流行的 Vue、React、Go、Node.js,越来越多的项目都开始采用「前后端分离」架构。那么,它到底解决了哪些问题?又为什么逐渐成为现代 Web 开发的主流?

    前言

    如果你接触过早期的网站开发,应该对这样的架构并不陌生。

    浏览器发起请求,服务器负责处理业务逻辑、查询数据库、渲染 HTML 页面,最后再返回给浏览器。

    整个流程看起来十分简单:

    浏览器
       │
       ▼
    PHP / Java / ASP.NET
       │
       ▼
    MySQL
    

    对于小型网站来说,这种模式开发效率很高,但随着业务越来越复杂,它的局限性也开始逐渐显现。

    什么是前后端分离?

    很多人第一次听到「前后端分离」,都会误以为只是把一个项目拆成两个项目。

    其实并不是。

    前后端分离真正的核心思想只有一句话:

    页面负责展示,服务负责数据。

    浏览器不再直接请求页面,而是通过 API 获取数据。

    整个流程变成了:

    浏览器(Vue / React)
            │
            ▼
         REST API
            │
            ▼
    Go / Java / Node.js
            │
            ▼
     MySQL / Redis
    

    后端不再负责拼接 HTML,而是统一返回 JSON 数据。

    前端则根据这些数据完成页面渲染。

    为什么越来越多人选择这种架构?

    1、一套接口,多端共享

    传统网站通常只有 PC 页面。

    后来又陆续出现了:

    • H5 页面
    • 微信小程序
    • Android App
    • iOS App
    • 桌面客户端

    如果还是采用传统模式,就意味着需要重复开发很多业务逻辑。

    而前后端分离之后:

    Vue
    React
    Flutter
    UniApp
    小程序
       │
       ▼
     同一套 API
    

    所有客户端都可以调用同一套接口。

    开发效率得到大幅提升。

    2、前端体验更流畅

    现代前端框架拥有很多优秀的能力,例如:

    • 组件化开发
    • 路由管理
    • 状态管理
    • 动画过渡
    • 局部刷新

    用户切换页面时,不需要重新加载整个网站。

    整个操作体验会更加丝滑。

    这也是为什么现在很多网站看起来更像一款桌面软件。

    3、后端更加专注

    以前的后端开发需要同时负责:

    • 页面模板
    • HTML
    • CSS
    • SQL
    • 业务逻辑

    项目越来越大之后,代码会变得非常臃肿。

    采用前后端分离之后,后端只需要关注:

    • 用户认证
    • 数据处理
    • 权限控制
    • API 设计

    页面展示完全交给前端完成。

    职责更加清晰,也更容易维护。

    前后端分离有哪些优势?

    总结下来,大致可以归纳为下面几点。

    优势 说明
    开发效率更高 前后端可以同时开发
    多端共享 一套 API 支持多个客户端
    更容易维护 职责划分更加清晰
    更方便扩展 后续增加 App、小程序成本更低
    部署更加灵活 前端、后端可以独立部署

    对于中大型项目来说,这些优势非常明显。

    有没有缺点?

    任何架构都不是万能的。

    前后端分离同样存在一些问题。

    SEO

    如果只是普通 SPA 应用,搜索引擎可能无法很好地抓取页面内容。

    因此现在很多项目都会采用:

    • SSR(服务端渲染)
    • SSG(静态站点生成)
    • ISR(增量静态生成)

    来兼顾 SEO 和用户体验。

    项目数量增加

    以前只有一个项目。

    现在可能会变成:

    frontend
    backend
    gateway
    nginx
    redis
    mysql
    

    开发、部署、运维都会稍微复杂一些。

    不过随着 Docker 的普及,这些问题已经没有以前那么明显了。

    所有项目都适合前后端分离吗?

    其实并不是。

    如果只是:

    • 企业官网
    • 个人博客
    • 宣传页面
    • Landing Page

    传统开发模式依然非常高效。

    但是如果项目包含:

    • 用户中心
    • 管理后台
    • App
    • 小程序
    • 开放 API
    • 第三方接入

    那么采用前后端分离会更加合适。

    我的理解

    在我看来,前后端分离最大的意义,并不是使用了 Vue、React 或者 Go。

    真正重要的是:

    让不同的系统各司其职。

    前端专注于用户体验。

    后端专注于业务逻辑。

    数据库专注于数据存储。

    每一层都有自己的职责。

    当项目越来越大时,这种架构带来的维护优势会越来越明显。

    如果这篇文章对你有所帮助,欢迎收藏、分享,也欢迎交流你对前后端分离架构的理解。

  • PHP 8.4.21同时安装 OPcache 和 mbstring 后出现 502

    PHP 8.4.21同时安装 OPcache 和 mbstring 后出现 502

    mbstring 扩展本身并不会导致 502 错误。 如果同时安装了 OPcache 和 mbstring 后出现的 502,问题几乎可以肯定是 OPcache 引起的

    为什么安装了 OPcache 就会 502?

    问题的根源在于 PHP 8.4.21 版本中,OPcache 扩展的 JIT(即时编译)功能与当前环境存在不兼容。这可能会导致 PHP-FPM 进程因为”段错误”而崩溃,Nginx 在无法连接到后端时就会返回 502 错误。

    解决方案(二选一)

    方案一:关闭 OPcache 的 JIT 功能(推荐,保留基础缓存)

    这个方法可以保留 OPcache 的脚本缓存加速能力,同时解决 502 错误。

    1. 定位配置文件:
      在宝塔面板的 软件商店 -> PHP 8.4 设置 -> 配置文件 中修改。

    2. 修改参数:
      在配置文件中找到 opcache.jit_buffer_size 这一行,将其值改为 0。如果找不到这行,可以手动添加。

    修改前:

    opcache.jit_buffer_size=128m
    

    修改后:

    opcache.jit_buffer_size=0
    

    这个修改会关闭 JIT 功能,但 OPcache 的字节码缓存功能依然生效,对绝大多数网站的性能影响很小。

    最后重启 PHP

    方案二:暂时卸载 OPcache 扩展

    如果修改 JIT 配置后问题依旧,或者想彻底排查,可以直接卸载 OPcache 扩展。

    1. 在宝塔面板的 PHP 8.4 设置中,切换到 安装扩展 标签页。

    2. 找到 opcache,点击 卸载。

    3. 卸载后网站会立即恢复正常。