新闻详情

新闻详情

首页 / 资讯中心 / 详情

健身类小程序前后端源码落地指南:微信登录、训练计划与打卡链路解析

发布时间:2026/9/26 8:03:44来源:尧图网络
健身类小程序前后端源码落地指南:微信登录、训练计划与打卡链路解析
简介一套完整的健身类小程序前后端源码面向有小程序开发基础、希望快速搭建或二次开发健身运动类应用的开发者也适合作为相关课程设计与毕业设计的参考。资源以前后端分离方式组织后端基于Laravel框架环境要求PHP 7.2、Laravel 5.6提供用户管理、运动课程、健康数据等接口前端为微信小程序端weapp目录并使用HBuilder可导入运行同时附带基于AdminLTE的后台管理界面。压缩包共584个文件以PHP逻辑代码189个、JavaScript交互脚本104个、CSS样式87个和PNG图片93个为主另含Vue组件、SQL数据库脚本、字体文件及配置文件整体约3.13MB目录划分清晰便于按模块查阅。目前已有399人学习使用对于想要掌握小程序前后端协作、学习Laravel接口开发或直接部署健身类项目的人来说能节省从零搭建的时间与精力是一份实用的工程参考。1. 健身类小程序前后端源码先跑通骨架再去加花活不少私教工作室、健身房或者个人开发者手里买到过一套健身类小程序前后端源码打开压缩包一看前端是微信小程序后端是一堆 Java 或 PHP 接口数据库脚本放在某个不起眼的目录里。真正想把它跑起来的时候才发现最大的障碍不是业务逻辑而是微信登录态怎么换、Token 放哪、请求域名怎么配这一连串的“连点”。这套源码的定位就是给你一个能直接跑的骨架课程展示、训练计划、打卡记录、数据统计这些核心功能都帮你串好了你要做的是把业务皮肤换掉而不是从零开始搭地基。适合谁去投入有 Java 或 JavaScript 基础、想快速验证健身私教方向的从业者以及接外包需要一套稳定底座的独立开发者。反直觉的地方在于这套源码里最难抄的不是业务代码而是“微信生态对接”那段——登录、支付回调、订阅消息这些黑匣子经验不足的人卡三天都不奇怪。2. 先定架构再动手技术栈选型、缓存策略与目录拆解先想清楚一件事这套源码采用的是前后端分离架构。小程序端只管渲染和采集用户行为后端只出 JSON 数据两者用 HTTP 接口通信。为什么不用服务端渲染的模板方案因为微信小程序的运行环境是独立的审核要求、更新机制都和网页不同前后端分离是当前从业环境下最稳的落地方式。2.1 前端选型原生微信小程序还是 uni-app常见做法是用原生微信小程序因为微信生态的 API 支持最直接调试工具成熟社区资料也最多。用 uni-app 的也有好处是一套代码以后还能编译到 Android、iOS、鸿蒙坏处是每个平台都有兼容坑你得多背一份黑匣子成本。如果这套源码本身就是原生语法写的我建议你先别折腾跨端老老实实先把原生跑通等业务稳定了再考虑用 uni-app 重写。前端源码里值得研究的是它的请求封装和页面结构。多数健身小程序会把页面分成首页、训练计划页、打卡页、我的页这几个 tab每个 tab 下再挂业务子页面。组件库方面新手最稳的选择是 Vant Weapp注意版本要和微信基础库匹配不然会出现样式错乱这种玄学问题。2.2 后端选型Spring Boot 当家的理由和替代方案后端选型要看这套源码是用什么写的。目前市场上最常见的健身类前后端源码后端是 Spring Boot 加 MyBatis配 MySQL 数据库。Spring Boot 的好处是生态全、招人容易、部署简单一个 jar 包就能跑。换 PHP 或者 Node.js 也行但你要确认自己能否搞定依赖安装——PHP 的扩展版本问题、Node 的包版本冲突都是新手最容易翻车的点。拿到源码第一步先看后端有没有带 Redis 配置。很多健身小程序会用到 Redis 存验证码、token 黑名单或者排行榜数据。如果源码里带了 Redis 配置而你本地没装建议先把这部分注释掉用本地缓存顶替先把主流程跑通再补基础设施。依赖越少你跑通源码的概率越高。2.3 项目目录拆解与数据库表设计拿到源码后先别急着双击那个启动类先看目录结构。一个规范的后端工程应该是这样的backend/ ├── pom.xml ├── src/main/java/com/example/fitness/ │ ├── controller/ # 接口层 │ ├── service/ # 业务层 │ ├── mapper/ # 数据访问层 │ ├── entity/ # 数据实体 │ ├── config/ # 配置类如拦截器、跨域配置 │ └── common/ # 统一返回体、异常处理 ├── src/main/resources/ │ ├── application.yml │ └── mapper/ # MyBatis XML └── sql/ └── init.sql # 表结构初始化脚本前端目录通常是这样miniprogram/ ├── app.js ├── app.json ├── pages/ │ ├── index/ # 首页 │ ├── plan/ # 训练计划 │ ├── checkin/ # 打卡 │ └── profile/ # 我的 ├── api/ # 接口封装 ├── utils/ # 工具类 └── components/ # 自定义组件数据库表是整个系统的心脏健身类小程序最少需要四张表CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) UNIQUE NOT NULL COMMENT 微信openid唯一标识, nickname VARCHAR(64), avatar_url VARCHAR(255), level INT DEFAULT 1 COMMENT 训练等级决定计划难度, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_course ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(128) NOT NULL, cover_url VARCHAR(255), video_url VARCHAR(255), duration INT COMMENT 时长单位分钟, calories INT COMMENT 消耗千卡, category VARCHAR(32) COMMENT 如减脂、增肌 ); CREATE TABLE t_plan ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, plan_date DATE NOT NULL, course_id INT NOT NULL, status TINYINT DEFAULT 0 COMMENT 0未完成 1已完成, UNIQUE KEY uk_user_date (user_id, plan_date) ); CREATE TABLE t_checkin ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, plan_id INT NOT NULL, checkin_date DATE NOT NULL, duration_seconds INT COMMENT 实际训练秒数, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_checkin (user_id, checkin_date) );注意 design 上的两个唯一索引t_plan里每个用户每天只有一条计划t_checkin里每个用户每天只能有一条打卡记录。这两个约束就是防重复的逻辑闸门代码层漏了还有数据库兜底。3. 后端落地微信登录、训练计划与打卡统计三个核心链路后端源码的价值集中在三个链路上登录换 token、按日期生成训练计划、打卡后更新连续天数。这三个链路跑通了整个小程序的用户体系就活了。3.1 登录链路先用 code2Session 换 openid再签发自己的 token微信小程序的登录分两步。第一步前端调wx.login()拿到一个临时 code这个 code 有效期只有五分钟而且只能用一次。第二步后端拿着 code 去微信的接口换 openid。openid 是你这个小程序里的用户唯一标识同一个用户在不同小程序里 openid 不一样所以千万不要拿 openid 去做全局用户关联。先看后端配置文件server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/fitness_db?useUnicodetruecharacterEncodingutf8 username: root password: your_password redis: # 本地没有 Redis 可以注释掉这段 host: localhost port: 6379 wx: appid: wx1234567890abcdef secret: abcdef1234567890abcdef1234567890 jwt: secret: your-own-secret-key-please-change expire-hours: 72wx.appid和wx.secret在微信公众平台的“开发管理-开发设置”里拿注意 secret 泄露后可以在平台重置这是你的后悔药。jwt.secret是签发登录令牌的密钥务必改成随机长字符串默认值上线前必须换。登录接口的核心逻辑RestController RequestMapping(/api/auth) public class AuthController { private final WxService wxService; private final UserMapper userMapper; private final TokenService tokenService; public AuthController(...) { ... } PostMapping(/login) public Result login(RequestBody LoginRequest req) { // 1. 用 code 换取 openid String openid wxService.code2Session(req.getCode()); if (openid null) { return Result.error(登录失败请重试); } // 2. 查用户是否存在不存在则注册 User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); userMapper.insert(user); } // 3. 签发自己的登录令牌 String token tokenService.generate(user.getId()); return Result.ok(token); } }逻辑说明第一步先检查 openid 是否为 null换 openid 失败的原因一般是 code 过期或者 appid/secret 配置错。第二步用 openid 查用户查不到就插入新用户这一步叫“静默注册”用户无感知。第三步签发 token 给前端后续所有请求带上这个 token后端就能识别你是谁。参数说明LoginRequest只需要一个code字段。Result是统一返回体格式一般为{ code: 0, message: ok, data: ... }code 为 0 表示成功非 0 表示失败。前端判断成功与否只看这个 code不要拿 HTTP status code 判断业务成功。3.2 训练计划接口按日期生成懒加载策略最省事训练计划的功能逻辑是用户打开小程序看到今天的训练任务做完打卡。最简单的实现是“懒生成”——用户第一次请求今天的数据时后端根据用户的训练等级生成一条计划存到t_plan表里之后每次请求直接查表返回。GetMapping(/plan/today) public Result todayPlan(RequestParam Integer userId) { LocalDate today LocalDate.now(); Plan plan planMapper.selectByUserAndDate(userId, today); if (plan null) { // 根据用户等级挑选一个合适的课程 Course course courseMapper.randomByLevel(user.getLevel()); plan new Plan(); plan.setUserId(userId); plan.setPlanDate(today); plan.setCourseId(course.getId()); planMapper.insert(plan); } return Result.ok(plan); }逻辑说明先查今天的计划查不到再生成。这里面有个细节——randomByLevel按用户等级随机挑选课程只适用于练前水平差不多的场景。如果你想让计划更科学应该在t_plan里加一个plan_sequence字段按序列循环课程表避免用户连续一周练同一个部位。参数说明plan_date字段存的是日期不要存时间戳否则按天查询时还要做时间区间转换。UNIQUE KEY uk_user_date (user_id, plan_date)确保了同一个用户同一天只会有一条计划就算并发请求来了也不会插重。3.3 打卡逻辑与连续天数统计先查重、再写入、最后更新统计打卡是健身小程序里最容易写崩的接口。用户点一次“我练完了”前端可能因为网络抖动连发两次请求如果不做防重数据库里就会出现两条打卡记录连续天数统计也跟着错。PostMapping(/checkin) public Result checkin(RequestBody CheckinRequest req) { // 1. 先查今天是否已打卡 int count checkinMapper.countByUserAndDate(req.getUserId(), LocalDate.now()); if (count 0) { return Result.error(今天已经打过卡了); } // 2. 插入打卡记录 Checkin checkin new Checkin(); checkin.setUserId(req.getUserId()); checkin.setPlanId(req.getPlanId()); checkin.setDurationSeconds(req.getDurationSeconds()); checkinMapper.insert(checkin); // 3. 更新连续天数 streakService.update(req.getUserId()); return Result.ok(); }逻辑说明第一步先查再插防止重复提交。第二步插入记录durationSeconds是用户实际训练时长前端要传真实数据。第三步更新连续天数更新策略是昨天打过卡则连续天数加 1昨天没打则重置为 1。参数说明req.getPlanId()来自训练计划接口的返回值前端存到页面 data 里打卡时原样带回。这里要特别留意计划是每天的但打卡是按用户和日期约束的所以理论上今天可以打卡任意计划。如果你的业务要求必须打今天的卡后端还要加一步校验planId对应的计划日期必须是今天。4. 小程序前端落地请求封装、打卡页交互与动态标题后端的接口设计得再干净前端封装不到位运行起来一样是白屏、报错、用户流失。前端源码的质感主要看三块请求统一封装、页面交互逻辑、标题与缓存细节。4.1 请求封装token 注入、超时设置与错误码统一处理所有的小程序页面都会调接口如果每个页面都写一遍wx.request项目里就会出现几十段重复代码改一个接口域名要全局搜索替换。规范的源码一定会有一份请求封装// api/request.js const BASE_URL https://api.example.com // 上线前改成自己的域名 function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method: method, data: data, timeout: 8000, // 8 秒超时超过就走上限 header: { Content-Type: application/json, Authorization: Bearer wx.getStorageSync(token) }, success(res) { if (res.statusCode 401) { // token 过期清除本地登录态跳回登录页 wx.removeStorageSync(token); wx.removeStorageSync(userInfo); wx.navigateTo({ url: /pages/login/login }); return; } if (res.data.code ! 0) { wx.showToast({ title: res.data.message || 请求失败, icon: none }); reject(res.data); return; } resolve(res.data.data); }, fail(err) { // 网络断了或超时 wx.showToast({ title: 网络开了小差, icon: none }); reject(err); } }); }); } module.exports { request };逻辑说明BASE_URL单独拎出来方便切换开发环境和生产环境。每次请求自动带上 headertoken 从本地缓存里取。401 状态码专门处理登录态失效这里注意小事——清掉 token 后要跳登录页但不能用wx.redirectTo跳否则登录成功后返回不了原页面。参数说明timeout: 8000是个经验值。健身打卡页用户可能边练边看倒计时网络慢一点也要能容忍但对于支付类接口我建议单独调到 10 秒以上。res.data.code是后端业务状态码和 HTTP 状态码要区分开——HTTP 200 只能说明请求通了业务是否成功要看 code 是否为 0。4.2 训练打卡页倒计时、提交打卡与本地缓存防重打卡页是用户使用频率最高的页面。交互流程是看今天的训练计划点开始训练页面进入倒计时训练结束后点提交打卡。// pages/checkin/checkin.js Page({ data: { plan: null, seconds: 0, timer: null, isCounting: false }, onLoad(query) { this.loadTodayPlan(); }, loadTodayPlan() { const userId wx.getStorageSync(userId); request(/plan/today?userId userId).then((plan) { this.setData({ plan: plan }); }); }, startTraining() { this.setData({ isCounting: true }); // 每秒加一注意 setInterval 要存 id离开页面时清理 this.data.timer setInterval(() { this.setData({ seconds: this.data.seconds 1 }); }, 1000); }, submitCheckin() { const today this.getDateStr(); // 本地缓存命中直接阻止重复提交 if (wx.getStorageSync(checked_ today)) { wx.showToast({ title: 今天已经打过卡了, icon: none }); return; } request(/checkin, POST, { userId: wx.getStorageSync(userId), planId: this.data.plan.id, durationSeconds: this.data.seconds }).then(() { // 打卡成功后写本地缓存有效期为当天 wx.setStorage({ key: checked_ today, data: true, // 缓存过期时间由后台清理或隔天覆盖即可 }); wx.showToast({ title: 打卡成功 }); this.setData({ isCounting: false }); }); }, getDateStr() { const d new Date(); return d.getFullYear() - (d.getMonth() 1) - d.getDate(); } });逻辑说明startTraining里启动计时器seconds累加后回显到页面用户提交时把真实训练秒数传给后端。submitCheckin先用本地缓存做一次防重命中缓存直接拦截这个策略在弱网环境下能避免用户反复点击造成的重复请求。参数说明wx.setStorage默认没有过期时间这里我们按业务日期做 keychecked_2026-05-20第二天自动失效不需要手动清。这个方法比wx.setStorage的success回调里再setTimeout删缓存靠谱得多少一个定时器就少一个崩溃点。4.3 动态设置页面标题与组件库选型健身小程序里有很多需要动态改标题的场景用户从训练计划列表页点进一个课程标题要变成课程名用户从打卡记录进到历史详情页标题要变成日期。只靠app.json配置静态标题是远远不够的。wx.setNavigationBarTitle({ title: 今日训练 this.data.plan.courseTitle });这段代码放在onReady生命周期里执行不要放在onLoad因为页面渲染完成后再改标题更稳定偶尔放在onLoad里会出现标题闪现一下又变回去的情况。组件库用 Vant Weapp 或者微信官方扩展库都行关键是要在app.json里注册{ usingComponents: { van-button: vant/weapp/button/index, van-cell: vant/weapp/cell/index, van-tabbar: vant/weapp/tabbar/index } }组件库版本和微信基础库的兼容是另一大坑Vant Weapp 新版本要求基础库 2.6.0 以上老用户微信版本过低会出现组件不渲染。个人经验组件库不要追新锁在一个稳定大版本微信基础库的兼容测试放到真机上跑一遍再发版。5. 前后端联调避坑域名白名单、登录态失效、图片加载与上传校验骨架搭好后联调是真正出问题的地方。下面这五条是健身类小程序里出现频率最高的踩坑记录按“现象 → 原因 → 解决”整理。5.1 手机预览白屏数据全不出来request 合法域名没配现象开发工具里一切正常一到手机真机预览就白屏控制台报https://api.example.com 不在以下 request 合法域名列表中。原因微信小程序有域名白名单机制真机环境只允许请求已经在小程序后台配置过的域名。开发者工具默认开了“不校验合法域名”选项掩盖了这个问题。解决登录微信公众平台在“开发管理-开发设置-服务器域名”里把接口域名加入 request 合法域名。注意三点域名必须是 HTTPS、不能带端口、ICP 备案必须完成。如果你只是本地调试可以临时用开发者工具的“不校验合法域名”选项但不能把这个当长期方案。5.2 token 过期后所有接口报 401用户却毫无提示现象用户挂机半小时回来点“开始训练”按钮页面无反应控制台全是 401。原因后端 token 过期后接口返回 401但前端拿到 401 后没有统一处理页面代码里只处理了code 0的情况其他状态全部静默失败。解决必须在请求封装的 401 分支里做统一跳转清理本地登录态引导用户重新登录。我一般还会额外加一个细节跳登录页前用wx.showModal提示“登录已过期请重新登录”避免用户莫名其妙被踢出去。5.3 图片加载不出来的概率性问题COS 跨域与缓存时间现象课程封面图在开发工具里能显示真机上有时候能显示、有时候裂图尤其是换了网络环境后。原因图片存储用的是云 COS 或 OSS但存储桶的跨域规则没配置或者 CDN 缓存时间设置得太长旧图片资源被缓存后又被删掉。解决先去存储桶控制台配置跨域规则AllowedOrigin填*AllowedMethod填 GET 和 HEAD。缓存时间按图片类型区分课程封面这类可能更新的图缓存时间设置 1 天完全固定的图标类可以设置 30 天。如果图片还是加载不稳定把图片 URL 从 HTTPS 证书是否完整的角度再查一遍。5.4 文件上传被后端拦下只校验文件后缀是最大的漏洞现象小程序端上传头像或视频后端一直返回“文件格式不支持”但明明传的是.jpg。原因不少源码的后端上传接口只校验文件后缀名比如判断.jpg、.png。而小程序上传的文件名可能带随机字符串或者后缀字母大写.JPG导致正则匹配失败。解决不要只校验后缀。正确做法是读取文件头几个字节判断真实类型JPEG 的文件头是FF D8 FFPNG 的文件头是89 50 4E 47。文件类型判断和扩展名校验双通过才保存这也是防止恶意文件上传绕过后端过滤的基本姿势。5.5 支付回调验签不过钱扣了订单状态没变现象用户支付成功后小程序端收到成功提示但后端订单状态还是“待支付”。原因微信支付的回调地址没配或回调签名校验逻辑写错了。最常见的是拿req.getParameter()取回调参数但微信支付回调的 XML 数据放在 body 里要解析 body 而不是拿参数。解决按微信官方要求写一个专门的回调接口PostMapping(/api/pay/notify)接收 XML 后先验签验签通过再更新订单状态。本地测不了回调我一般用内网穿透临时暴露一个公网地址来测测完立刻关掉。上线后注意回调地址必须是已经备案的 HTTPS 域名。6. 发布前的验证脚本用 curl 和 SQL 把核心链路过一遍源码跑通以后最容易忽略的是上线前验证。我习惯先把核心接口用脚本扫一遍再对着数据库核对比团队里十个人手动点一遍可靠得多。第一个脚本是登录加调接口的链路测试#!/bin/bash # 验证登录 - 拉今日计划 - 提交打卡 BASE_URLhttps://api.example.com # 1. 用测试 code 登录拿到 token TOKEN$(curl -s -X POST $BASE_URL/api/auth/login \ -H Content-Type: application/json \ -d {code:test_code_001} | jq -r .data.token) echo 拿到 token: $TOKEN # 2. 拉今日计划 curl -s $BASE_URL/api/plan/today?userId1 \ -H Authorization: Bearer $TOKEN | jq # 3. 提交打卡 curl -s -X POST $BASE_URL/api/checkin \ -H Content-Type: application/json \ -H Authorization: Bearer $TOKEN \ -d {userId:1,planId:1,durationSeconds:1800} | jq这里的test_code_001是后端留的测试开关生产环境要关掉。脚本跑完以后再进数据库核对落库数据SELECT u.openid, COUNT(c.id) AS checkin_days FROM t_user u LEFT JOIN t_checkin c ON u.id c.user_id GROUP BY u.id; SELECT plan_date, status FROM t_plan WHERE user_id 1 ORDER BY plan_date DESC LIMIT 7;第一段 SQL 看用户打卡天数是否连续第二段看最近七天的计划生成是否正常。我吃过一次亏token 过期时间设了 365 天结果用户换手机号登录后旧 token 依然有效后来改成 72 小时过期加刷新机制才把问题控制住。这套验证方法虽然朴素但每一次发布前跑一遍能帮你挡掉至少八成低级故障。希望帮到你。本文还有配套的精品资源点击获取
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

体育馆预约平台源码拆解:SpringBoot+Vue+MyBatis企业级实现 2026/9/26 8:45:52

体育馆预约平台源码拆解:SpringBoot+Vue+MyBatis企业级实现

企业级体育馆预约平台源码拆解:从业务模型到落地实践如果你在学校体育馆、商业球馆或者单位文体中心待过,一定见过这样的场景:高峰期场地被挤爆,空闲时段却空着没人来;前台电话被预约咨询打到占线;几个人同…

阅读更多 →
Agent技能库实战:从巨型Prompt到可加载能力单元的设计与落地 2026/9/26 8:45:52

Agent技能库实战:从巨型Prompt到可加载能力单元的设计与落地

做Agent应用做得多了,你会发现一个很扎心的规律:项目前期最耗时的往往不是写代码,而是“调那个越来越长的Prompt”。今天能回答,明天答非所问,加一个功能就要在系统提示词里再叠一段,最后连自己都分不清哪条…

阅读更多 →
Atlas 300V 24G部署YOLO实战:从NPU认知到性能调优 2026/9/26 8:45:52

Atlas 300V 24G部署YOLO实战:从NPU认知到性能调优

有人问“atlas 300V 24G 是运算加速卡吗”,紧接着又有人问“atlas部署yolo怎么搞”,这两个问题放在一起看,基本说明大家对这款卡有需求但还不太摸得清门路。我最近刚好在一台服务器上把YOLOv5和YOLOv8的检测服务都跑到了Atlas 300V上&#xf…

阅读更多 →
以沟通为核心线索的CRM设计:从理念到落地实践 2026/9/26 8:45:52

以沟通为核心线索的CRM设计:从理念到落地实践

1. 整体设计:为什么要把"沟通"作为CRM的核心线索1.1 名字背后的产品思路DeskcommCRM,拆开看就是Desk(桌面)、Comm(Communication,沟通)和CRM的组合。这个名字不是拍脑袋起的&#xff…

阅读更多 →
从“形式审查”到“开放协作”:代码审查流程改造实践 2026/9/26 8:45:52

从“形式审查”到“开放协作”:代码审查流程改造实践

1. 为什么我最终把代码审查做成了"开放式"的 先说一个我自己踩出来的结论: 代码审查这件事,开放程度决定了它到底是质量保障手段,还是团队内耗源头。 早年我在一家小团队带项目,代码审查基本靠"领导抽检后端互看…

阅读更多 →
Atlas 300V加速卡部署YOLO推理实战:硬件解析、模型转换与调优 2026/9/26 8:45:46

Atlas 300V加速卡部署YOLO推理实战:硬件解析、模型转换与调优

1. 先说清楚:Atlas 300V 到底是什么看到标题里挂着"atlas"这个词,再配上"atlas部署yolo"和"atlas 300v 24g 是运算加速卡吗"这两个热搜,我基本能断定你十有八九是被华为昇腾的Atlas系列给绕进去了。先直接回答…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉