可行，但需适配serverless模型：重定向storage/cache/views等路径至/tmp、改用stderr日志、array或redis会话、通过入口文件接管http请求而非artisan serve，并禁用本地文件依赖。
直接在云函数中运行 Laravel 应用是可行的，但不是简单“上传代码就能跑”。核心在于适配 Serverless 的执行模型——无状态、短生命周期、只读文件系统、临时存储限制。Laravel 原生设计依赖持久化服务（如 Apache/Nginx、长驻进程、本地缓存与日志目录），而云函数环境恰好相反。因此，部署成功的关键不是替换框架，而是重定向 Laravel 的 I/O 行为、接管启动流程，并绕过所有对持久文件系统的硬依赖。
必须重定向的 Laravel 运行时路径
云函数（如腾讯云 SCF、AWS Lambda）仅允许写入 /tmp 目录，其余路径（storage/、bootstrap/cache/）默认不可写，会导致缓存生成失败、配置加载报错、日志写入中断。需通过环境变量或代码层强制覆盖：
-
缓存路径：修改
config/cache.php中file.path指向/tmp/storage/framework/cache/data -
视图编译路径：设置
VIEW_COMPILED_PATH=/tmp/storage/framework/views，并在部署前手动创建该目录（如在scf_bootstrap中mkdir -p /tmp/storage/framework/views） -
日志通道：将
LOG_CHANNEL设为stderr，确保日志实时输出到云函数控制台，避免写入storage/logs -
Session 驱动：禁用
file或database，改用array（仅限无状态 API 场景）或对接 Redis（需外置云数据库）
入口控制与 HTTP 服务接管
Laravel 默认依赖 php artisan serve 启动内置服务器，但在云函数中，你不能长期监听端口。正确做法是用一个轻量级入口文件（如 index.php 或 scf_bootstrap）作为函数 handler，把每次 HTTP 请求转换为一次 Laravel 内核请求：
- 不启动
artisan serve，而是通过require_once 'vendor/autoload.php';+$kernel = app(\Illuminate\Contracts\Http\Kernel::class);手动触发请求生命周期 - 静态资源（
.js、.css、.png等）需由入口文件识别路径并直接读取/var/user/public/下对应文件，返回原始内容或 base64 编码后的二进制（图片类） - API 请求则交由 Laravel 路由分发，响应体需按云函数要求格式封装（如含
statusCode、headers、body字段）
构建与部署的最小必要动作
跳过本地开发习惯，聚焦云函数约束下的精简流程：
- 项目根目录下新增可执行脚本
scf_bootstrap（权限755），内容包括环境变量注入（SERVERLESS=1、APP_STORAGE=/tmp/storage）和启动逻辑 - 删除
.env文件，所有敏感配置通过云函数控制台的环境变量注入（如DB_HOST、REDIS_URL） - 使用模板部署可跳过大部分改造（如腾讯云 WebFunc 的 Laravel 模板已预置路径重写和启动逻辑），适合快速验证；自定义部署则需手动完成上述路径与入口调整
- 内存配置建议 ≥512MB，保障 Composer 自动加载和视图编译不超时；冷启动延迟可通过预留并发或函数预热缓解
Serverless 不是 Laravel 的替代方案，而是它的新运行时容器。真正落地时，重点不在“能不能跑”，而在“哪些 Laravel 特性必须让渡”——比如放弃本地队列驱动、不用 php artisan tinker、不依赖 storage/app 存用户上传文件（应转存至 COS/S3）。理解这个边界，部署就不再神秘。
