前端部署:从开发到生产的最后一公里

前端部署:从开发到生产的最后一公里

毒舌时刻

前端部署?这不是运维的事吗?

"我只负责写代码,部署交给运维"——结果部署失败,互相甩锅,
"我直接把文件上传到服务器"——结果更新不及时,缓存问题频发,
"我用FTP上传,多简单"——结果文件传丢,网站崩溃。

醒醒吧,前端部署是前端开发的重要环节,不是别人的事!

为什么你需要这个?

  • 快速上线:自动化部署,减少人工操作
  • 环境一致性:确保开发、测试、生产环境一致
  • 回滚能力:出现问题时可以快速回滚
  • 监控和日志:实时监控网站状态和错误

反面教材

# 反面教材:手动部署 # 1. 本地构建 npm run build # 2. 手动上传文件 ftp ftp://example.com > put -r dist/* # 3. 手动清除缓存 ssh [email protected] > rm -rf /var/www/html/* > cp -r dist/* /var/www/html/ > systemctl restart nginx # 4. 手动检查 curl https://example.com 

正确的做法

# 正确的做法:使用CI/CD # .github/workflows/deploy.yml name: Deploy to Production on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Setup Node.js uses: actions/setup-node@v3 with: node-version: '18' cache: 'npm' - name: Install dependencies run: npm ci - name: Build run: npm run build - name: Test run: npm test - name: Deploy to Vercel uses: amondnet/vercel-action@v25 with: vercel-token: ${{ secrets.VERCEL_TOKEN }} vercel-args: '--prod' vercel-org-id: ${{ secrets.VERCEL_ORG_ID }} vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }} 
# 正确的做法:使用Docker # Dockerfile FROM node:18-alpine AS build WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build FROM nginx:alpine COPY --from=build /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] 
# 正确的做法:Nginx配置 # nginx.conf server { listen 80; server_name example.com; root /usr/share/nginx/html; index index.html; # 处理单页应用路由 location / { try_files $uri $uri/ /index.html; } # 静态资源缓存 location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { expires 30d; add_header Cache-Control "public, max-age=2592000"; } # Gzip压缩 gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; } 
// 正确的做法:使用CDN // vite.config.js import { defineConfig } from 'vite'; import react from '@vitejs/plugin-react'; export default defineConfig({ plugins: [react()], build: { outDir: 'dist', assetsDir: 'assets', // 生成带哈希的文件名,便于缓存 rollupOptions: { output: { entryFileNames: 'assets/[name].[hash].js', chunkFileNames: 'assets/[name].[hash].js', assetFileNames: 'assets/[name].[hash].[ext]' } } }, // 配置CDN base: 'https://cdn.example.com/' }); 

毒舌点评

看看,这才叫前端部署!不是简单地手动上传文件,而是使用CI/CD、Docker、CDN等现代化工具。

记住,前端部署不是一次性的任务,而是一个持续的过程。你需要考虑构建优化、缓存策略、回滚机制等多个方面。

所以,别再觉得部署是运维的事了,它是你作为前端开发者的责任!

总结

  • CI/CD:使用GitHub Actions、GitLab CI等自动化部署
  • Docker:使用容器化技术,确保环境一致性
  • CDN:使用内容分发网络,提高访问速度
  • 缓存策略:合理设置缓存,减少重复请求
  • 监控:使用监控工具,实时了解网站状态
  • 日志:收集和分析日志,快速定位问题
  • 回滚:准备回滚方案,出现问题时快速恢复
  • 环境变量:使用环境变量管理不同环境的配置

前端部署,让你的代码快速、安全地到达用户手中!

Read more

在昇腾NPU上跑Llama 2模型:一次完整的性能测试与实战通关指南

在昇腾NPU上跑Llama 2模型:一次完整的性能测试与实战通关指南

目录 * 在昇腾NPU上跑Llama 2模型:一次完整的性能测试与实战通关指南 * 引言:从“为什么选择昇腾”开始 * 第一幕:环境搭建——好的开始是成功的一半 * 1.1 GitCode Notebook 创建“避坑指南” * 1.2 环境验证:“Hello, NPU!” * 第二幕:模型部署——从下载到运行的“荆棘之路” * 2.1 安装依赖与模型下载 * 2.2 核心部署代码与“坑”的化解 * 第三幕:性能测试——揭开昇腾NPU的真实面纱 * 3.1 严谨的性能测试脚本 * 3.2 测试结果与分析 * 第四幕:性能优化——让Llama跑得更快 * 4.1 使用昇腾原生大模型框架 * 4.

本地多模型切换利器——Llama-Swap全攻略

本地多模型切换利器——Llama-Swap全攻略

运行多个大语言模型(LLM)非常有用: 无论是用于比较模型输出、设置备用方案(当一个模型失败时自动切换)、还是实现行为定制(例如一个模型专注写代码,另一个模型专注技术写作),实践中我们经常以这种方式使用 LLM。 一些应用(如 poe.com)已经提供了多模型运行的平台。但如果你希望完全在本地运行、多省 API 成本,并保证数据隐私,情况就会复杂许多。 问题在于:本地设置通常意味着要处理多个端口、运行不同进程,并且手动切换,不够理想。 这正是 Llama-Swap 要解决的痛点。它是一个超轻量的开源代理服务(仅需一个二进制文件),能够让你轻松在多个本地 LLM 之间切换。简单来说,它会在本地监听 OpenAI 风格的 API 请求,并根据请求的模型名称,自动启动或停止对应的模型服务。客户端无需感知底层切换,使用体验完全透明。 📌 Llama-Swap 工作原理 概念上,Llama-Swap 就像一个智能路由器,

虚幻版Pico大空间VR入门教程 05 —— 原点坐标和项目优化技巧整理

虚幻版Pico大空间VR入门教程 05 —— 原点坐标和项目优化技巧整理

大空间头显坐标朝向 一体机p4ue设备开启大空间定位识别,并框选障碍物范围,暂时不用Marker贴图精细定位。 大空间一体机范围设置文档:https://business.picoxr.com/cn/doc/Enterprise-LBE-Bestcase 非企业版设备(具体设备型号查看02章节),如果没有内置大空间功能,则需要使用第三方定位,例如RTK,ubw。 通过UE5默认的VR项目模板,修改SetTrackingOrigin记录:(括号内为UE5.3及以前旧版本枚举选项) OpenXR有线串联模式下, Stage、View(eye、EyeLevel)、Local floor(StandFloor、FloorLevel)、Local(SitFloor)、customOpenXR模式下,大空间标记障碍物和VR场景障碍物匹配, Reset Orientation and Position 则以当前玩家的位置和头显正朝向作为场景默认初始点; (如果玩家朝向东南时触发重置头显,则在VR游戏内,现实世界的东南朝向为VR游戏内的正北, 在大空间模式下需要特别注意重置头显操作,否

盘古200Pro+开发板高速通信指南:6.6Gbps光纤+PCIe x4性能实测

盘古200Pro+开发板高速通信实战:从6.6Gbps理论到稳定传输的工程化路径 对于从事通信系统、数据中心互联或高速数据采集的工程师而言,一块标称性能强劲的FPGA开发板到手后,最令人兴奋也最具挑战的环节,莫过于将手册上的理论速率转化为稳定、可靠的实测性能。紫光同创的盘古200Pro+开发板(基于PG2L200H FPGA,型号MES2L676-200HP)以其高达6.6Gbps的HSST收发器速率和PCIe x4接口,吸引了众多追求高性能国产化方案开发者的目光。然而,在真实的工程环境中,如何驾驭这些高速接口,确保数据传输的完整性与低延迟,远非接上光纤或插入PCIe插槽那么简单。本文将从一个实践者的角度,深入探讨如何在这块开发板上实现光纤与PCIe链路的高性能通信,分享从时钟优化、眼图分析到系统级调优的全流程实战经验。 1. 硬件平台深度解析与高速链路设计要点 盘古200Pro+开发板采用核心板加扩展底板的架构,其高速通信能力的基石在于紫光同创Logos2系列PG2L200H FPGA内嵌的HSST(High-Speed Serial Transceiver)模块。官方宣称每