2026 PrestaShop 开源电商服务器租用实测：PHP/MySQL/插件/并发 6 维对比 + 避坑避雷全攻略

2026 PrestaShop 开源电商服务器租用实测：PHP/MySQL/插件/并发 6 维对比 + 避坑避雷全攻略

这篇不是安装教程，也不是官方文档的翻译。我们站在「租服务器」的视角，把 PrestaShop 这套基于 PHP/Symfony 的开源电商系统，在真实托管场景里要吃掉多少 CPU、内存、磁盘、带宽、电力和机位，一项一项拆开算清楚。和站内已经写过的 nopCommerce（.NET）、Bagisto（Laravel）、OpenCart（轻量 PHP）不同，本篇只盯 PrestaShop 自己的技术栈特征：Symfony 框架、模块（官方叫模块，社区习惯叫插件）生态、后台与前台的并发差异，以及缓存与索引这两个最容易被忽视的隐性成本。读完后你应该能拿一张配置表去机房或云厂商询价，而不是被销售话术牵着走。

谁会用 PrestaShop 搭自己的电商站

PrestaShop 诞生于法国，在欧洲中小商户里根基很深，官方开源项目自 2007 年持续运营至今。它的典型用户画像和 Shopify 这类 SaaS 抽成型平台是错位的：愿意自己租服务器、自己管数据库、自己背运维责任，但换来了零交易佣金、源码完全可控、可以魔改任意环节。跨境卖家是多语言多币种需求最重的一群人，PrestaShop 原生支持多商店、多语言、多货币，后台一套商品可以映射到不同国家站点，这点比很多需要靠插件硬凑的竞品顺手。

另一类用户是预算敏感但有开发能力的团队。他们不想每年给 SaaS 交订阅费，也不想把客户数据锁在别人云里，于是选择把 PrestaShop 跑在自租的 LAMP/LEMP 服务器上。这类站点往往前期流量不大，但商品图多、SKU 杂、插件装得勤，等到大促才发现资源账没算明白。还有一类是接外包的建站公司，给客户交付一套可迁移的电商站，客户自己续费服务器，运维交接时最容易踩的坑就是环境不一致。

反过来说，如果你只是想明天就开张、完全不懂命令行，PrestaShop 未必是首选，它的部署和调优门槛明显高过一键式 SaaS。本篇默认读者是「准备自己租服务器跑 PrestaShop」的决策者或运维，所以全文围绕资源、选型、雷区三条线展开。

还有一个被低估的群体是品牌独立站运营者。他们可能在 Shopify 上起步，做到一定规模后不满于模板同质化和订阅抽成，想迁移到可完全掌控的栈上。PrestaShop 的源码开放让他们能改结账流程、接自有 ERP、做深度会员体系，而不必受平台功能边界限制。只是这类迁移的隐性成本在人力：主题要重写或移植、历史订单与会员数据要清洗迁入、SEO 权重在新域名或新结构上要重新养。所以「谁该用」的答案里，技术可控性要排在「免费」之前——你能驾驭它的复杂度，它才省钱。

PrestaShop 的技术栈与运行模型（PHP/Symfony/MySQL/Apache 或 Nginx）

先说清楚它到底跑在什么上面，因为资源账全是从技术栈反推出来的。PrestaShop 9 基于 Symfony 6.4 框架，要求 PHP 8.1 及以上，官方推荐 PHP 8.4（后续版本也建议 8.5 这类较新分支）；数据库是 MySQL 5.7 或 MariaDB 10.2 起，越新越稳；Web 服务器兼容 Apache 2.4 与 Nginx 1.0+，生产环境几乎清一色走 Nginx + PHP-FPM。官方明确建议每个 PHP 脚本的 memory_limit 至少 512M，并且反复强调 OPcache 必须开启——这不是可选项，而是性能的地基。

运行模型上是典型的 PHP 应用：每次 HTTP 请求由 Nginx 转发给 PHP-FPM 的一个 worker 进程，worker 加载 Symfony 容器、连 MySQL、跑模块钩子（hook）、渲染 Smarty 模板，最后把 HTML 吐回去。前台是访客看的商品页、分类页、搜索页、购物车与结账页；后台（Advanced Parameters / 模块 / 订单）是商家操作面，逻辑更重、SQL 更多。CDN 通常只前置静态资源（图片、CSS、JS、字体），动态请求最终还是要回源到 PHP。

这里有个容易误判的点：PrestaShop 9 引入了 Admin API 与全新的 Hummingbird 主题（基于 Bootstrap 5 + TypeScript），后台界面重做过，但底层仍是 Symfony 容器加大量历史模块钩子。也就是说，它不是一个「轻量 PHP 小站」，而是一个有框架开销、有对象缓存需求、有后台任务（cron 索引、邮件、统计）的电商操作系统。下面六维拆解，就是把这套运行模型翻译成服务器账单。

顺带理清一个版本误区：PrestaShop 8 与 9 的 PHP 基线不同，8 代推荐 PHP 8.1，9 代抬到 8.1+ 并鼓励 8.4/8.5；MySQL 一侧 5.7 是底线，MariaDB 则从 10.2 起。升级大版本时，除了核心，最该先核对的是已装模块的兼容声明，很多「升级后后台白屏」的根因是某个老模块还没跟上 Symfony 新版本。开发期 PrestaShop 还依赖 Composer、NodeJS 20.x 与 Webpack 来编译前端资源，但这些只在构建阶段需要，生产运行时并不需要 Node，别把它们也装进生产机白白占资源。另外 allow_url_fopen 必须在 php.ini 里设为 On，否则支付回调等远程拉取会失败，这是部署清单里容易被漏掉的一项。

六维拆解：CPU 与 PHP-FPM 进程（结账与搜索的峰值）

第一维是 CPU，也是最容易被低估的一项。PHP 请求是并行分布在多核上的，但单条请求绝大部分时间只占用一个核心，所以「少而快的核心」比「多而慢的核心」更划算。真正吃 CPU 的是三类场景：页面渲染（Symfony 容器启动、模板编译）、搜索与筛选（layered navigation 做大量 SQL 聚合）、以及结账（库存校验、价规则计算、支付回调校验）。一次 Black Friday 压测里，一个 8 核单机的 PrestaShop 站把 CPU 顶到 80% 以上，订单处理时间比目标慢了将近四成，问题不在数据库——监控显示 MySQL 线程很少、没有锁等待，瓶颈纯在 PHP 处理层，等于每台访客都在现场重新算页面。

PHP-FPM 的进程池是关键旋钮，核心参数是 pm.max_children。经验上每个 PrestaShop worker 常驻内存约 200MB 上下（具体看装了多少模块），要按「剩余内存 ÷ 单 worker 内存」去反推能开多少进程，而不是凭感觉拍脑袋。开太少，并发一来请求在 FPM 队列里排队，TTFB（首字节时间）直接飙高；开太多，内存被打满触发 swap，整台机器反而更慢，还会把 MySQL 连接数顶爆。建议配合 pm.max_requests 定期回收 worker，避免某个模块内存泄漏把进程越养越大。VPS 上还要盯 steal time（被宿主机抢占的 CPU），这项高说明邻居在抢资源，换服务器比加核更治本。

实务上，中小店 2–4 个 vCPU 够用，中大型促销前要把 CPU 余量留到 1.5 倍峰值以上，并用 PHP-FPM slow log 找出慢脚本——是某个控制器慢、某个模块钩子慢，还是一次同步的外部 API 调用卡住了 worker。定位清楚再决定加核还是改代码，否则加再多核也只是给慢请求提供了更多排队通道。

还有一个细节常被运维忽略：PHP-FPM 的 pm 模式选 dynamic 还是 static 要看内存是否充裕。内存紧就 dynamic 配 pm.start_servers、pm.min_spare_servers、pm.max_spare_servers，让进程数随负载浮动；内存足且流量平稳可 static 直接固定 worker 数，省去伸缩开销。无论哪种，都要配合 listen.backlog 与进程存活监控，避免队列默默堆积。压测时不要只打首页——首页往往能缓存，真正吃算力的是分类页、搜索页和结账，这三类的并发表现才代表大促真实水位。CPU steal time 高说明宿主机超卖严重，这时加核只是从邻居嘴里抢时间，换服务器才是正解。

六维拆解：内存（OPcache、MySQL 缓冲与模块加载）

第二维是内存，它同时养着三个大户：PHP-FPM worker、MySQL/MariaDB 缓冲池、以及 Redis/Memcached 这类内存缓存。OPcache 必须单独给它留空间，官方与社区一致建议 opcache.memory_consumption 至少 256MB，max_accelerated_files 设到 20000 以上，生产环境把 validate_timestamps 关掉、靠部署时手动清缓存来保证代码更新生效。没有 OPcache，每一次请求都要重新编译上千个 PHP 文件，TTFB 能差出 30%–50%，这是免费且必须拿到的性能。

MySQL 的 innodb_buffer_pool_size 是另一个内存黑洞，单服务器部署时通常占整机 25%–40% 的 RAM，目标是让热点表和数据索引尽量待在内存里，别每次查询都落盘。再往上叠 Redis 或 Memcached 做对象缓存与会话（session）存储，社区经验是在高并发下能把数据库查询量砍掉 30%–60%。模块加载本身也吃内存——每个启用的模块都要注册钩子、可能加载自己的类与配置，这就是为什么「关掉不用的模块」往往比「加内存」更立竿见影。

除了 OPcache，realpath_cache_size（256K–512K）这类小参数也值得调，能减少 PHP 反复解析文件路径的开销。脚本级 memory_limit 建议 256M–512M，CLI 端的批量导入、重建索引任务可以单独放宽到 0 或更高，但 Web 请求侧别无脑调大，否则一个卡死脚本就能吞掉一整个 worker 的配额。内存这维的底线是：永远给操作系统和文件系统缓存留 10%–20% 的余量，别把 RAM 算到分毫不剩。

提一句 APCu：在部分环境下 APCu 作为本地对象缓存后端比 Redis 更轻，适合单机且不愿再养一个内存服务的场景，但它是单机本地的，多服务器横向扩展时就要回到 Redis 这种可共享的后端。选择哪种，取决于你处在单机档还是规模档。另一个现实约束是 swap——当内存真被打满，系统会把部分页换到磁盘，I/O 骤增、延迟翻倍，电商站宁可限死 worker 数让少量请求排队，也别放任 swap 默默发生，监控里要把 swap 使用量当作红色指标。realpath 缓存、OPcache interned strings 缓冲这些「小参数」在目录文件极多的站点上也值得调大，能减少 PHP 反复解析路径与字符串的开销。

六维拆解：SSD 与商品图片/订单写入

第三维是磁盘，重点在「快」和「稳」而非容量。PrestaShop 的商品图由 GD 扩展生成缩略图，一个 SKU 往往派生出多套尺寸（列表、详情、购物车、首页卡片），目录一大，图片目录的体积增长非常可观；订单、客户、日志则持续写入 MySQL。把这些放在 SATA 机械盘上，分类页和搜索页的随机读写会直接拖垮体验。生产环境强烈建议 SSD，预算宽裕直接上 NVMe，I/O 延迟的下降对数据库和图片缩略图生成都是肉眼可感。

磁盘另外两个隐患容易被忽略：一是 MySQL 的数据目录和临时表目录要分开规划，避免大查询的临时文件把系统盘写满；二是图片目录的权限，PrestaShop 需要 Web 用户能写，但写权过大又是被扫的入口，要在「能生成缩略图」和「不被任意上传执行」之间取平衡。备份策略也得跟着磁盘走——商品图和订单库是核心资产，至少做一份异地或对象存储的周期性快照，别等磁盘故障才想起来。

容量本身反而最好估算：商品图按「SKU 数 × 每 SKU 派生图数 × 平均单图体积（WebP 后通常远小于原图）」粗算，数据库按订单与日志增长速度留两年余量。比起纠结买 500G 还是 1T，更该确认的是磁盘类型、是否支持在线扩容、以及 IOPS 是否被云厂商限了上限。

数据库日志与 binlog 也会持续吃盘，尤其开启复制或做时间点恢复时，binlog 保留策略要设上限并定期清理，否则悄无声息把数据盘写满、MySQL 直接拒绝写入、订单卡死。图片这边，建议上传原图后由系统统一派生 WebP 缩略图，不要把原图直接推给前端；原图单独归档或转对象存储，热图走 CDN，这样本地 SSD 只扛热数据与数据库，容量和 IOPS 都更从容。RAID 也要想清楚：追求读性能可 RAID 10，追求容量与冗余可 RAID 1/5/6，但 RAID 不是备份，磁盘阵列崩了仍需独立备份兜底。电商站最怕的不是慢，是数据没了，所以磁盘策略永远要和备份策略一起设计。

六维拆解：带宽（商品图、列表页与支付回调）

第四维是带宽，电商站的流量结构很特殊：单个页面里图片往往占 60%–80% 的重量，所以吞带宽的主力不是 HTML，而是商品图、分类列表的图墙、以及首页大图。一个服饰类目页几十张缩略图同时下发，没做图优化和 CDN 前置的话，月流量会涨得比预期快得多。支付回调、加购、下单这些动态请求反而数据量很小，但它们对延迟敏感，断一秒可能就丢一单。

带宽账要分境内外两条线算。如果你的客户集中在国内，静态资源走国内 CDN 边缘服务器能显著降源站回源量；如果是跨境多国访客，CDN 把图片和 CSS/JS 缓到离客户近的服务器，源站带宽压力进一步摊薄。无论哪条线，图片格式用 WebP（必要时 AVIF）、开启 Gzip/Brotli 压缩、给静态资源设长缓存（Cache-Control 带长 max-age 与版本化文件名）都是必做项。这样同样的出口带宽能服务更多并发，相当于间接省了带宽账单。

需要提醒的是，本篇不虚构任何具体带宽数值或测速结果，实际带宽需求请以你的真实商品图体量、日均 PV 与促销峰值去测算；租用前可要求服务商提供「公开带宽」或「参考预算」口径的报价，并以官网实时或沟通确认为准，别拿网上的示例数字当承诺。

带宽计费模式也要看清：包月固定带宽、按 95 峰值计费、按流量计费三种逻辑完全不同。固定带宽简单可控但峰值外溢会限速；95 峰值适合有短暂大促尖峰的店；按流量则平时便宜、爆款时账单可能跳涨。跨境站还要算清境内外回源成本——图片若没被 CDN 兜住，每一次海外访客都直接打回国内源站，带宽费和延迟一起爆炸。所以带宽这维的优化重心其实在前面：图压小、静态上 CDN、动态请求瘦身后，出口带宽需求自然降下来，谈价时也更有底气。别一上来就猛加带宽，先确认是不是该缓存的没缓存。

六维拆解：电力（常驻电商站 7x24）

第五维是电力，电商站没有「下班关机」这回事，7x24 常驻是硬要求。你租的每一台机器背后都连着机房的供电、UPS 与柴油发电机冗余，这部分成本已经折进机位租金里，但选机房时仍要问清电力保障等级——是否双路市电、是否有不间断电源与燃油备份、单机柜供电上限多少。一次大促断电半小时，损失的订单和口碑往往超过一年电费差价。

电力维度还和稳定性绑定：同机房里别的客户若跑满算力把供电或制冷压到极限，你的机器也可能被波及降频。所以高密度机柜、散热设计、以及服务商对单机功耗的约束，都是 7x24 电商站该关心的隐性指标。对个人或小团队来说，与其自己买设备托管，不如直接租整机和机位一体化交付，把电力、制冷、网络出口都交给机房，自己只管系统和业务。

从成本结构看，电力这维在账单上通常表现为「机位费 + 带宽费」的组合，而非单独的每度电费。谈单时把常驻运行、峰值功耗上限、制冷是否另收费问清楚，比单纯比对每小时单价更有意义。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营服务器与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时或咨询确认为准。

六维拆解：机位与部署形态（反向转发、HTTPS、CDN 前置）

第六维是机位与部署形态，它决定你这台机器在机房里怎么摆、流量怎么进来。最朴素的形态是一台机器包揽 Web、PHP、MySQL、缓存全部角色，适合起步期；成长后第一刀往往把 MySQL 拆到独立服务器或独立实例，让数据库有自己的缓冲池和连接上限，避免和 PHP 抢内存。再往上，可以在前面架 Nginx 反向转发或 Varnish 做全页缓存，把匿名访客的商品页、分类页在边缘就直接返回，源站 PHP 几乎不碰——社区实测这类全页缓存能吃掉匿名页 90% 的服务器时间，TTFB 从数百毫秒压到百毫秒内。

HTTPS 是电商的底线，TLS 终止建议放在反向转发层，并启用 HTTP/2 或 HTTP/3 以复用连接、降低多资源页面的延迟。CDN 前置只负责静态资源与可缓存的匿名页，购物车、结账、登录、账号、支付回调这些带状态的请求必须回源并严禁缓存，否则会出现「把 A 客户的购物车吐给 B 客户」的严重事故。全页缓存的失效策略也极关键：商品价格、库存、促销规则一变就要精准清对应缓存，不能只靠 TTL 兜底。

机位层面，单机柜能放几台、是否支持私有交换机、是否能拉 BGP 多线（让不同运营商访客都走最优路径）都是部署形态的一部分。对跨境站，把源站放在离主要客户近的服务器、CDN 覆盖其余地区，是比盲目堆单机配置更聪明的做法。机位和部署不是越复杂越好，而是和你的流量结构、团队运维能力匹配。

插件生态的取舍（模块过多拖慢站点）

PrestaShop 的模块（插件）生态是它最大的卖点，也是最常见的性能陷阱。官方 Addons 市场加上第三方开发者，能找到支付、物流、邮件、SEO、营销、评论、多语言几乎一切功能。但每个「启用」的模块都不是免费的：它会注册钩子，在几乎每个页面渲染时执行；它可能往每一次渲染塞自己的 SQL 查询且常常不缓存、不建索引；它可能把 JS/CSS 全站排队加载；还有的模块在页面生成时同步调用外部 API，外部一卡，worker 就跟着卡。

因此「模块审计」是性价比最高的一次性动作：列清所有已装模块，标出「必需 / 有用 / 闲置」，先把闲置的禁用乃至卸载；对仍保留的重度模块，检查它的钩子能否从不需要的控制器上解绑。重灾区有三类：分层筛选（layered navigation）在每次筛选都跑大量未缓存的聚合 SQL，必须给筛选表建索引并激进缓存、减少 facet 数量；「猜你喜欢 / 买了又买」类跨卖模块，每个商品页都做昂贵 join，建议换成缓存结果或人工精选列表；统计类模块在每次访问都写库，应改到客户端分析。一次性把查询数从 300+ 压下来，TTFB 的改善经常比加内存更明显。

另一个取舍是「大而全模块 vs 专注小模块」。一个宣称包揽 SEO+营销+社交的巨无霸模块，往往比三个各司其职的小模块更重更难排查。选模块时看它是否支持缓存、是否只在需要的页面加载、是否有官方对当前 PrestaShop 版本的兼容声明，比看功能列表长短更重要。

还有一个反直觉的坑：免费模块往往比付费模块更危险。免费模块的维护者可能随时停更，漏洞没人修，而它又常因「不要钱」被一股脑装上。装之前看三件事——最后更新时间、兼容的 PrestaShop 版本区间、评论里有没有「升级后崩了」的反馈。对核心链路（支付、登录、结账）上的模块尤其苛刻，宁可少一个花哨功能，也别让一个来路不明的模块坐在订单流程里。模块更新也别「一键全升」，先在 staging 逐个升、逐个验，再回生产，这是电商站少宕机的纪律。模块数量本身不是原罪，原罪是「启用了却用不上」和「来源不可信」。

几类电商系统对比（PrestaShop / WooCommerce / OpenCart 客观维度）

把 PrestaShop 和常被一起比较的几套系统放在同一张表里，能更直观地看出它适合什么、不适合什么。下面只列客观技术维度，不替你下「谁更好」的结论——选型永远取决于团队技能与业务形态。

这张表刻意把 Bagisto 也放进来，是为了和站内其它篇章形成对照：Bagisto 走 Laravel、OpenCart 走极简 PHP、WooCommerce 寄生在 WordPress 上，而 PrestaShop 的核心识别度就是 Symfony 框架 + 原生多店多语 + 厚重模块生态。选它的人，通常是在为「欧洲跨境 + 自托管 + 不接受 SaaS 抽成」这组需求买单。

部署 PrestaShop 的常见雷区（后台慢、被扫、索引缺失）

雷区一：后台慢。表现是新装挺快，装了几十个模块、跑了半年后后台点一下转好几秒。根因常是 Symfony 缓存目录不可写或权限错乱、模块钩子在后台也疯狂执行、cron 任务（邮件、索引、统计）没设或卡死在前台请求里。排查先开 PHP-FPM slow log，再看 /var/cache 是否可写、是否该清而未清。

雷区二：被扫与被攻。PrestaShop 的后台路径默认是 /admin-随机串，但很多人改回 /admin 或把随机串设得太短，成为批量爆破目标；allow_url_fopen 开着本是为支付等远程拉取所需，但也扩大了攻击面，必须配合好文件权限与 WAF；从不明来源装模块、PHP 扩展长期不更新、上传目录可执行，都是常见入口。建议后台路径保持长随机、启用双因素、限制后台 IP 段、模块只从官方或可信开发者处取。

雷区三：索引缺失。商品一多，分类页、搜索页、分层筛选的 SQL 开始全表扫描，MySQL 线程堆起来、CPU 跟着涨。ps_ 系列表里价格、分类、库存、语言等关键字段如果没有合适索引，促销时直接雪崩。对策是定期用慢查询日志抓长 SQL、给筛选与排序字段补索引、把 MyISAM 表统一到 InnoDB、并调好 innodb_buffer_pool_size。索引这步不在租用阶段做，上线后迟早要还。

雷区四：图片与缓存权限错配。缩略图生成要求写权限，但写权过大等于给上传执行开绿灯；OPcache 与 Symfony 缓存目录权限不对，会导致清了缓存却不生效、或缓存被任意改写。这类问题表象是「改了没反应」「白屏」，本质是权限模型没设计。

雷区五：PHP 扩展缺失或版本错。PrestaShop 强依赖 CURL、DOM、Fileinfo、GD、Intl、JSON、Mbstring、OpenSSL、PDO_MYSQL、SimpleXML、Zip 等扩展，少一个要么装不上、要么某功能静默失效（比如 Intl 缺失导致多币种显示错乱，GD 缺失导致缩略图不生成）。部署清单里应把扩展逐项核对，而不是等上线后排查半天。雷区六：cron 没配。PrestaShop 的邮件队列、搜索索引、某些统计与清理任务依赖定时执行，cron 缺失时这些任务堆在前台请求里同步跑，访客就成了免费劳动力，体验断崖式下跌。部署完成第一件事就该把 cron 调通并验证日志，否则后台慢、邮件发不出、索引不更新会轮流找上门。

选型建议与服务器配置参考（PrestaShop 篇）

下面给三档参考配置，但请注意这仅是「参考预算」级别的思路，不是承诺参数，最终机型、带宽与报价请以官网实时或沟通确认为准。

起步档（日 PV 数千、SKU 数百、单机托管）：2–4 个 vCPU、4–8GB 内存、SSD 系统盘与数据盘分离、Nginx + PHP-FPM + MySQL 同机、OPcache 与 Smarty 缓存全开、Redis 用本机实例做对象与会话缓存。这档够小店平稳跑，瓶颈先出现在促销峰值而非日常。

进阶档（日 PV 数万、SKU 数千、有营销活动）：4–8 个 vCPU、8–16GB 内存、NVMe、MySQL 缓冲池给到内存的 30% 上下、Redis 独立或同机但留足内存、前面加 Nginx 反向转发与 CDN 前置静态资源、全页缓存只覆盖匿名页。这档要开始把数据库和 PHP 的资源边界划清。

规模档（大促、跨境多服务器、SKU 上万）：MySQL 拆独立服务器并单独调优、Web/PHP 可横向加服务器配负载均衡、Redis 用于会话与队列、CDN 覆盖主要客户区域、源站放近客户群服务器并拉 BGP 多线。这档拼的不是单机多强，而是分层与弹性。

带宽与机位按前文的流量结构去谈「公开报价」，别被「无限流量」话术带偏，看清是共享还是独享、是否有峰值限速。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营服务器与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；如需为电商站点定制带高带宽与弹性机位的服务器方案，可直接联系一万网络确认机型与交付周期。

常见问题与避坑要点（PrestaShop 篇）

问：PHP 版本该怎么选？答：PrestaShop 9 支持 PHP 8.1 及以上，推荐 8.4/8.5 这类较新分支，但不要盲目追新——先确认你装的所有支付与自定义模块都声明兼容，否则一次升级可能让结账挂掉。生产环境升级前务必在 staging 跑一遍结账全流程。

问：OPcache 是不是开了就行？答：开了只是及格。还要给它留足内存（256MB 起）、把 max_accelerated_files 调够、生产关掉 validate_timestamps 并靠部署清缓存。OPcache 内存不够时缓存会被频繁踢出，性能回到接近没开。

问：Redis 和全页缓存哪个先上？答：Redis 做对象与会话缓存收益最稳，几乎无副作用，优先；全页缓存收益最大但风险也最高，必须只缓存匿名页、排除购物车/结账/账号，并配好失效策略，没把握就先别碰。

问：为什么分类页比首页还慢？答：分类页和搜索页是 SQL 聚合重灾区，尤其分层筛选。先查慢查询日志、补索引、给筛选结果加缓存、减少 facet 数量，比加 CPU 更对症。

问：迁移到新服务器要注意什么？答：环境对齐（PHP 版本、扩展、OPcache、MySQL 版本）、文件与数据库整体搬迁、缓存目录权限、cron 重建、以及后台路径与模块来源一致性。迁移后一定跑一遍前台商品页、加购、结账、支付回调全链路。

问：被扫了怎么办？答：先改后台随机路径为更长串、限制后台访问 IP、启用双因素、下掉不明模块、升级 PHP 扩展与核心补丁、检查上传目录是否可执行。安全是持续动作，不是一次性配置。

把以上六维资源账、模块取舍、对比表与雷区串起来看，PrestaShop 的服务器租用逻辑就很清楚了：它是一套有框架开销、有模块负载、有后台重逻辑的 Symfony 电商系统，省钱的正确姿势是「该开的缓存全开、该关的模块全关、该建的索引全建」，而不是在裸机上硬扛。算清 CPU、内存、SSD、带宽、电力、机位这六笔账，再去谈机型与报价，你手里的配置表才站得住脚。