企业官网建设流程全解析

简介：Linux程序设计课程设计——记忆仓库微信小程序开发资料包，面向计算机相关专业在校生、教师及小程序初学者，解决课程设计、毕业设计或项目初期演示过程中缺乏完整可运行案例的问题。压缩包共176个文件，以js、wxml、wxss、json等前后端逻辑、页面结构与样式配置代码为主，png、jpg图片素材用于界面展示，docx实验报告和文档说明细致补充设计思路与运行要点，整体包体仅2.21MB，目录结构紧凑清晰，便于下载后快速定位。目前已有124人学习浏览，全部代码均测试运行成功，作者在课程答辩中获得平均96分的好成绩。除完整源代码外，配套实验报告记录了从需求分析到测试验收的完整流程，文档说明梳理了各文件模块的作用与部署注意事项；新手可在此基础上逐步理解Linux环境下的开发调试方式，有一定基础的读者也能继续扩展分类、检索、复习提醒等记忆仓库功能，是一份兼具可运行性与参考价值的课程设计资源。

1. Linux 课程设计做记忆仓库小程序：先想清楚交付什么

“Linux程序设计课程设计-记忆仓库微信小程序开发+源代码+文档说明+实验报告”这个标题，常让人误以为要在 Linux 上写个网页后端。拆开看，它其实是三件事合在一起：开发环境和工作流必须落在 Linux 上；交付的形态是微信小程序，功能叫记忆仓库——把知识点、单词、错题做成卡片，存进来并在复习时间点提醒你；交付物除了源代码，还要有文档说明和实验报告。评审老师拿到压缩包，最先看的是工程结构、数据库设计和报告逻辑，代码反而是最后才翻的。这门课设适合二三年级做课程设计的学生，也适合想用小程序给毕设攒原型的同学；如果你手里只有 Linux 笔记本，又担心没有官方开发者工具就没法开工，下面这套流程就是按这条路径跑的。

2. 技术栈先立住：Linux 下做小程序，原生与云开发怎么选

2.1 为什么推荐「原生小程序 + 云开发」而不是 uniapp 打包

先回答最纠结的选型问题。微信小程序有两条主流路线：一条是官方原生框架，wxml、wxss、js、json 四种文件各司其职；另一条是用 uniapp 或 Taro 这类跨端框架写一套 Vue/React 代码，再编译成小程序。放在“Linux程序设计”这个课设标题下，我更推荐原生，理由有三个。

第一，课程设计评审看的是代码组织能力。原生工程里一个页面就是一个目录，pages/index/index.js管逻辑、index.wxml管结构、index.wxss管样式、index.json管页面配置，老师翻开源码一眼能看懂。而 uniapp 交给你的是一堆 vue 文件和编译中间产物，答辩时很难用三句话讲清“哪一行代码对应界面上的哪一个按钮”。

第二，Linux 侧对原生工程的构建负担最小。原生小程序源码本质上就是一系列纯文本文件，写完后用命令行走查错、压缩、上传都方便；uniapp 工程则要先跑一遍 npm 依赖安装再 build，依赖版本一不一致，在 Linux 上编译就是一串红。课设时间本来就紧，不该把时间耗在这种地方。

第三，也是很多同学没意识到的：小程序后台可以不开服务器。原生小程序可以直接用微信云开发——云数据库、云存储、云函数都现成，不需要自己在 Linux 上部署 MySQL 或 Nginx。但这不代表标题里的 Linux 就不重要，Linux 在这里承担的是“研发环境”，不是“生产环境”。

接下来是后端要不要自己写。记忆仓库这种课设，数据量也就是几百张卡片，业务逻辑只有增删改查和提醒复习。我做过的不少课设里，给评审的答案是：云开发做数据托管，Linux 做开发与交付，两边都沾，但都不深。这张表可以帮你更直观地决定要不要在 Linux 上自建 API 服务：

需要说明，这里说的免费额度是云开发平台本身带的基础政策，不是我在带货；一张卡片几百条数据、每天几十次请求，课程设计完全够用。

2.2 Linux 开发环境的最小清单

我是用一台低配 Linux 笔记本把整个工程跑完的，不需要图形界面多华丽。系统推荐直接装 Ubuntu LTS 或任意国产 Linux 发行版，内核版本尽量新一点，内存 8GB 以上，普通 SSD 就够。装好系统之后，最小工具链如下：

• git：源代码管理用，至少要会git init、git add、git commit、git log四个命令
• Node.js LTS：小程序相关的命令行工具都建立在它上面，建议用 nvm 安装，避免系统包管理器自带的旧版本
• VS Code 或者 vim：写代码用。VS Code 装一个 wechat-miniprogram 扩展能补全 wxml 语法；vim 就纯当文本编辑器用
• miniprogram-ci：这是 Linux 上能否把代码包上传到微信后台的关键，后面会重点讲
• 一个能跑 bash 的终端：用来执行源码检查和构建脚本

安装完我一般会先跑三条命令确认环境是干净的：

git --version node -v npm -v

三条命令都输得出版本号，说明基础环境没问题。后面所有操作都在这个终端里做，把“程序设计”的过程沉淀在 shell 历史里，答辩时老师问“你怎么构建的”，你可以一条条翻出来讲。

如果你学校要求课设必须跑在 Linux 上，连文档都用 Markdown 写，那我更建议把整个工程的版本管理流程固定成三步：写代码前先git pull，写完后git add . && git commit -m "feat: 完成复习队列"，每天结束前git push。千万别等到最后一天才提交，源代码管理的过程分很大程度就是靠 commit 记录拿到的。

2.3 记忆仓库的核心数据模型：卡片、状态、时间戳

选完技术栈就得设计数据了。记忆仓库的最小实体是“卡片”，一张卡片至少要有内容、标签、复习状态、下次复习时间四个要素。我一般会在云开发里新建一个名为memos的集合，字段定义长这样：

{ "_id": "自动生成", "_openid": "创建者 openid，由云开发自动写入", "content": "Linux 中 chmod 755 表示所有者可读写执行，组和其他用户可读执行", "tags": ["linux", "常用命令"], "level": 1, "reviewCount": 0, "nextReviewAt": 1718000000000, "lastReviewedAt": 0, "createdAt": 1718000000000 }

这里要强调三个字段的设计理由。level表示这张卡片当前被记忆的牢固程度，1 是刚存入，最高我设到 5；每次复习答对就加，答错就减回 1。nextReviewAt存的是毫秒时间戳，不是字符串，后面讲坑的时候你会看到为什么必须这么做。_openid是云开发数据库里的用户标识，不需要自己生成，插入记录时云数据库会自动带上，页面查询时用它过滤当前用户的数据。

在云开发控制台里创建集合时，一定要把权限从默认的“仅创建者可读写”改掉，否则后面真机预览时只有你自己能看到，换一个体验成员就白屏。这个坑我放在第 5 章展开。数据结构定好后，前端所有页面就围绕这一张表展开：列表页读卡片、新增页写卡片、复习页改nextReviewAt。三个页面一个小程序，不用再做第二张表。

为了让 Linux 侧也看得见数据，我习惯在工程根目录放一个docs/data-model.md，把上面的字段用表格画出来，截图放进实验报告。这样评审不用登录微信后台，也能知道你设计了哪些字段。

3. 动手把记忆仓库拆成页面：列表、复习、写入三条链路

3.1 卡片列表与“加载更多”的正确写法

记忆仓库的首页是卡片列表。很多人上来就把所有卡片一次性get回来，几千条数据以下能跑通，但页面底部那个“上拉触底加载更多”是老师最喜欢问的点，建议一开始就按分页写。小程序原生里，页面滚动到底部会触发onReachBottom，我们要做的是维护一个page变量，每次加载查询 20 条。

// pages/index/index.js const db = wx.cloud.database() const memos = db.collection('memos') const PAGE_SIZE = 20 Page({ data: { cardList: [], page: 0, hasMore: true, loading: false }, async loadCards(reset = false) { if (this.data.loading) return this.setData({ loading: true }) const page = reset ? 0 : this.data.page const res = await memos .where({ nextReviewAt: db.command.lte(Date.now() + 24 * 3600 * 1000) }) .orderBy('nextReviewAt', 'asc') .skip(page * PAGE_SIZE) .limit(PAGE_SIZE) .get() const incoming = res.data.map(item => ({ ...item, timeText: this.formatTime(item.nextReviewAt) })) this.setData({ cardList: reset ? incoming : this.data.cardList.concat(incoming), page: page + 1, hasMore: incoming.length === PAGE_SIZE, loading: false }) }, onLoad() { this.loadCards(true) }, onReachBottom() { if (this.data.hasMore) { this.loadCards(false) } } })

逻辑说明：where里的db.command.lte是云数据库的“小于等于”查询条件，这里筛出来的是接下来 24 小时内该复习的卡片，配合orderBy把最紧迫的排在前面。skip和limit实现分页，每次取 20 条；hasMore判断这次是否取满，如果没取满就说明已经到底，不能再触发加载。

参数说明：把PAGE_SIZE调成 10 就是每页 10 条。需要留意的是，云开发基础版单次get最多返回 20 条，所以这个常量不能超过 20，否则会被服务端静默截断。代码里的reset参数用来区分“首次进入”和“翻页”，首次进入要直接覆盖列表，翻页则要 concat 拼接，这是列表加载最容易被忽略的分支。

3.2 记忆卡片的写入与编辑：表单校验和本地缓存

新增卡片的页面逻辑不复杂，但有两个点必须处理好：一是输入不能为空，二是写完要给用户即时反馈。我把表单页的提交函数拆成校验、入库、回调三部分：

// pages/new/new.js Page({ data: { content: '', tagInput: '' }, onContentInput(e) { this.setData({ content: e.detail.value }) }, async onSubmit() { const content = this.data.content.trim() if (!content) { wx.showToast({ title: '内容不能为空', icon: 'none' }) return } const tags = this.data.tagInput .split(/[,，、\s]+/) .filter(Boolean) .slice(0, 5) const now = Date.now() const db = wx.cloud.database() await db.collection('memos').add({ data: { content, tags, level: 1, reviewCount: 0, nextReviewAt: now + 24 * 3600 * 1000, lastReviewedAt: 0, createdAt: now } }) wx.showToast({ title: '已存入', icon: 'success' }) setTimeout(() => wx.navigateBack(), 800) } })

逻辑说明：标签字段允许用户用逗号、顿号或空格分隔，split之后filter(Boolean)去掉空串，slice(0, 5)限制最多 5 个标签，防止有人一口气录入十几二十个标签，把列表页样式撑坏。新卡片的nextReviewAt直接设为 24 小时后，也就是默认按一天后复习来调度。

参数说明：这里没有用 wx.storage 做本地缓存，因为云数据库本身已经是持久的，再写一份本地反而容易出现“本地有、云端无”的假象。但如果你的课设运行环境网络比较差，我一般会建议在onSubmit前先把内容存到wx.setStorageSync('draft', content)，等云端 add 成功后再删掉。这样小程序被杀掉重进，用户还能拿回草稿。这一招答辩现场尤其管用：万一云开发请求超时，你可以说“我做了本地草稿兜底”，而不是干瞪眼。

3.3 艾宾浩斯复习队列：一个不依赖服务器的调度算法

记忆仓库的核心卖点是“按时提醒复习”，这里不能每次都是固定 24 小时，而是要让已记住的卡片间隔越来越长。我用的是一套非常轻的艾宾浩斯变体：复习间隔按level翻倍，答错直接降回第一级。调度函数单独放在utils/scheduler.js里，方便在 Linux 上直接跑 Node.js 单测：

// utils/scheduler.js const BASE_INTERVAL_MS = 24 * 60 * 60 * 1000 function nextReviewPoint(level, pass) { if (!pass) return { level: 1, intervalMs: BASE_INTERVAL_MS } const newLevel = Math.min(level + 1, 5) const intervalMs = BASE_INTERVAL_MS * Math.pow(2, newLevel - 1) return { level: newLevel, intervalMs } } module.exports = { nextReviewPoint }

// utils/scheduler.test.js — 用 node 直接跑 const { nextReviewPoint } = require('./scheduler') const assert = require('assert') assert.strictEqual(nextReviewPoint(1, true).level, 2) assert.strictEqual(nextReviewPoint(1, false).level, 1) assert.strictEqual(nextReviewPoint(5, true).intervalMs, 24 * 3600 * 1000 * 16) console.log('scheduler test passed')

逻辑说明：答对时level从 1 涨到 2，复习间隔从 24 小时变成 48 小时；从第 1 级一路答对到第 5 级，间隔会变成 24、48、96、192、384 小时，符合“记得越牢，复习越稀疏”的直觉。答错时无论之前多高都直接降回第 1 级，这是很多背单词软件的做法，简单但有效。

参数说明：BASE_INTERVAL_MS这个基数可以按课设需求调，如果你想演示“三天后复习”的效果，把它改成3 * 24 * 3600 * 1000就行。这个调度函数的好处是，它可以脱离小程序直接在 Linux 终端用node utils/scheduler.test.js跑，测试通过后再接 UI。这就是标题里“Linux程序设计”能落在纸面上的证据：你在实验报告里写“调度算法通过 Node.js 单测验证”，比空口说一句“我做了复习功能”有说服力得多。

复习页拿到一张卡片时，只读取level和nextReviewAt，用户点“记住了”就把scheduler.nextReviewPoint(level, true)的结果写回数据库，点“没记住”就传false。整个闭环在前端就能完成，不依赖任何云函数。

4. 用 Linux 跑通小程序工程：命令行、代码检查与真机预览

4.1 为什么 Linux 上没有官方「微信开发者工具」也能开发

很多同学卡住的第一个问题就是：微信官方并没有提供 Linux 版微信开发者工具，下载页只有 Windows 和 macOS。这是事实，但课程设计要的不是“用官方 IDE 打开工程”，而是“能产出、能验证、能提交一个合格的小程序代码包”。

Linux 上没有官方 IDE 也能开发的根本原因，是小程序工程在源码阶段就是一堆纯文本文件：app.json声明页面和窗口，app.js做启动逻辑，每个页面四个文件一组。只要能编辑文本的操作系统，理论上都能开发。我全程在 Linux 上完成：用 VS Code 写代码，用git管理版本，用 bash 脚本做静态检查，最后用miniprogram-ci把代码包上传到微信后台。开发者工具更多是“可视化调试”，不是“能不能写代码”的分界线。

当然，没有 IDE 意味着不能实时看模拟器。我的替代方案是：代码写完后先做静态检查，然后miniprogram-ci上传一个预览版本，用手机微信扫码打开。这样循环一轮大概两分钟，比在 Windows 上开模拟器慢不了多少。真正的调试重点放在 console 和 vConsole 上，页面报错、网络请求、存储信息都能在上面看到。

4.2 用 miniprogram-ci 在 Linux 上完成上传与预览

miniprogram-ci 是微信官方出的命令行工具，可以在不打开 IDE 的情况下完成代码上传、预览、压缩等操作。在 Linux 上用它的完整步骤是这样的：

# 1. 在工程根目录安装 npm init -y npm install miniprogram-ci --save-dev # 2. 编写并执行上传脚本 node scripts/upload.js

需要先在scripts/upload.js里写一段调用逻辑：

// scripts/upload.js const ci = require('miniprogram-ci') const project = new ci.Project({ appid: 'wx你的小程序AppID', type: 'miniProgram', projectPath: __dirname + '/..', privateKeyPath: __dirname + '/../keys/private.key', ignores: ['node_modules', 'keys'] }) const upload = async () => { const res = await ci.upload({ project, version: '1.0.0', desc: '记忆仓库课程设计', setting: { es6: true, minify: true } }) console.log('上传成功', res) } upload().catch(err => console.error('上传失败', err))

逻辑说明：ci.Project的参数里privateKeyPath指向小程序后台“开发-开发设置-小程序代码上传密钥”里生成的私钥文件；projectPath指向工程根目录；ignores把依赖目录和密钥文件排除，避免密钥被一起打进代码包。ci.upload里的setting.es6表示把 ES6 语法转 ES5，minify表示压缩代码，这两个选项在小程序后台手动上传时也是默认开启的。

参数说明：私钥文件生成时微信后台要求绑定 IP 白名单，所以你必须先把 Linux 这台机器的公网出口 IP 填进小程序后台，否则命令会返回“IP 不在白名单”的报错。这里说的公网 IP 是校园网或云服务器的出口 IP，不是内网 192.168 地址，这一步最容易踩坑。

提示：公网 IP 如果是校园网分配的动态地址，可能几天变一次。我一般会在上传脚本里加一段curl ifconfig.me取当前出口 IP 的逻辑，上传前先核对后台白名单，省得报错后还要回头看配置。

上传成功后，在微信小程序后台的“版本管理”里就能看到刚提交的体验版，用手机扫码即可在真机上打开；如果想生成一个带参数的预览二维码，把ci.upload换成ci.preview即可，其他参数相同。Linux 上配合脚本，甚至能做到提交完自动打一个体验版二维码到终端，答辩时现场扫码演示是很有力的加分动作。

4.3 文档说明与实验报告的目录怎么组织

课设的分数很大一部分在压缩包的组织上。我见过太多人把所有文件平铺在根目录，评审下载下来第一眼看到的是十几个“新建文档(1).docx”，印象分直接归零。按下面的目录组织，基本不会出问题：

README.md要写清楚三个板块：这个项目是什么、运行需要什么、怎么在微信开发者工具里导入运行。代码里用到云开发，就在文档里写一句“需要先开通云开发并创建 memos 集合”，不要默认老师知道这些前提。实验报告目录另放，里面至少应包括需求分析、数据库设计、页面设计、核心代码说明、测试用例、总结与展望六块。第 6 章会给出报告里三张表的具体写法，那是答辩时最拉分的部分。

5. 避坑指南：从 JSON 解析到顶部导航栏高度，五个常踩的坑

5.1 上一轮的源码 zip 导入后打不开？先看 project.config.json

现象：很多课设是“接力型”的，拿上一届或者同学的源码 zip 改，导入微信开发者工具后提示“项目文件不存在”或者直接白屏。

原因：project.config.json里的miniprogramRoot指向了错误的子目录。有的工程把源码放在根目录，有的放在miniprogram/子目录，微信开发者工具是按照这个配置找代码的，路径对不上自然打不开。

解决：解压后先别急着导入，用cat project.config.json查看miniprogramRoot。如果源码在miniprogram/下，配置应该是这样：

{ "miniprogramRoot": "miniprogram/", "appid": "wx你的AppID", "compileType": "miniprogram", "setting": { "es6": true } }

然后把appid改成自己的，在开发者工具里重新导入。在 Linux 上用命令行查看这个文件特别顺手，我每接手一个旧工程都会先做这一步，省下大量“为什么打不开”的时间。另外提醒一句，上一轮的 zip 里如果有node_modules，直接删掉再导入，那些依赖是人家本地的，带过来只会让工具变慢。

5.2 顶部导航栏高度：不同机型的黑匣子

现象：页面顶部用自定义导航栏时，在 iPhone 上正常，换到 Android 或者全面屏机型，标题上移下移，按钮遮挡内容。

原因：微信小程序的导航栏由“状态栏高度 + 胶囊按钮”两部分决定，不同机型状态栏高度不同。你以为写死 44px 就够，实际 Android 机型有 48px、56px 的。

解决：不写死，用wx.getWindowInfo()动态读取：

const windowInfo = wx.getWindowInfo() const { statusBarHeight } = windowInfo const menuButton = wx.getMenuButtonBoundingClientRect() const navHeight = menuButton.height + (menuButton.top - statusBarHeight) * 2

逻辑说明：statusBarHeight是手机顶部系统状态栏的高度，menuButton是右上角胶囊按钮的位置信息。导航栏的视觉中心要跟胶囊按钮对齐，所以用胶囊按钮高度加上它的上下边距推导出导航栏总高度。这样无论换什么机型，自定义导航栏都不会顶头或者被刘海屏切掉。

在 Linux 上没有模拟器可看，这个坑测试起来最麻烦。我的做法是坚持“动态计算 + 真机预览一遍”，提交体验版后分别用 iPhone 和 Android 扫码看首页顶部。别偷懒，导航栏的玄学比业务代码的 bug 更让人头疼。

5.3 云开发数据库权限：读得到和写得进是两回事

现象：自己打开小程序能正常显示卡片，发给同学体验，对方页面一片空白；或者反过来，同学能看见所有人的卡片，隐私全暴露。

原因：云开发集合的权限设置由后台决定。默认的“仅创建者可读写”会导致非创建者读不到数据；而选成“所有用户可读”如果不谨慎，又可能把写入也放开。

解决：在云开发控制台里给memos集合选“所有用户可读，仅创建者可写”，这是课设最常用的权限组合。如果你会写安全规则，更精细一点是限定doc._openid == auth.openid。一定要在提交报告前测一遍“第二个微信账号访问”的场景，这是答辩老师最爱现场验证的。数据库权限不是写了代码就自动正确的，它是后台配置问题，代码里一点报错都看不到，只表现为页面白屏，这是最容易翻车的地方。

5.4 加载更多出现重复或跳漏：skip 分页的边界

现象：列表往下滑，“加载更多”加载出来的内容有时和上一屏重复，有时又跳过中间几条；快速翻页时尤其明显。

原因：skip + limit分页是“从头数第 N 条”，如果两次请求之间数据库集合有变化——比如你复习了一张卡片，nextReviewAt被更新了，排序位置就会移动，第二次请求按旧的skip数就会跳过或重复。

解决：不要用skip做无限滚动，改用“游标分页”。记住上一次请求返回的最后一条nextReviewAt和_id，下一页查询时加上nextReviewAt大于这个值的条件：

const lastCard = this.data.cardList[this.data.cardList.length - 1] const where = {} if (lastCard) { where.nextReviewAt = db.command.gt(lastCard.nextReviewAt) } const res = await memos.where(where).orderBy('nextReviewAt', 'asc').limit(PAGE_SIZE).get()

逻辑说明：nextReviewAt值最小的卡片最先被复习，复习后它的值会变大、排到后面去，用“大于上次最后一条”的条件就能保证新数据不会挤掉你还没看过的卡片。这个坑在课设里属于加分项，很多人根本意识不到，你能在答辩时讲出“游标分页替代 skip”，就已经超出平均水准了。

5.5 复习时间乱套：时间戳时区与本地字符串的错位

现象：明明设置了“24 小时后复习”，但第二天打开发现有的卡片已经过期好几个小时，有的还差很久。

原因：用new Date().toLocaleString()生成了带时区的本地时间字符串存进数据库。微信云端数据库存的是 UTC 时间，前端在小程序里显示时会按手机时区再转换一次，两边一来一回，就出现了几个小时到十几小时的偏差。

解决：存储一律用Date.now()得到的毫秒时间戳，展示时再格式化。调度算法里所有的“加 24 小时”都用24 * 3600 * 1000计算，不要用setHours这类依赖本地时区的方法。这条是我在 Linux 上用 Node.js 跑单测时发现的：同一个nextReviewPoint(1, true)，Linux 机器上 node 跑出来的结果和手机端算出来差了 8 小时，追了半天才发现是时区字符串的锅。统一成时间戳后，两边结果完全一致，这类问题再没出现过。

6. 验收与加分：把实验报告写成能跑通的技术说明

6.1 演示脚本：一分钟讲完记忆仓库

答辩前值得准备一条演示主线，顺序固定：打开小程序首页列表——演示刷新和上拉加载——新增一张卡片——回列表看到新卡片——进入复习页点“记住了”——回到首页看到这张卡片被推到更后面。这条线只需要 60 秒，但覆盖了增删查改四个核心操作，还顺带展示了调度生效的过程。Linux 侧再补一步：打开终端跑一遍node scripts/upload.js，让老师看到代码确实是从 Linux 环境构建上传的，而不是拿 Windows 截图糊弄人。

6.2 报告里的三张表和一张架构图

实验报告最容易写成流水账。我习惯在里面固定放三张表：数据表设计表（就是第 2 章那张memos字段表）、页面功能对照表（列出每个页面的入口、功能、涉及的数据集合）、测试用例表（正常新增、空内容校验、分页加载、复习调度、权限切换各一行）。另外手画一张“手机小程序页面 —— 云数据库 —— Linux 命令行工具”的架构简图，不需要多精美，PowerPoint 里的方框加箭头就够。这三表一图放进去，报告的可读性和分数通常立马上一个台阶。

6.3 最后一步，也是血泪经验

如果你想在 Linux 上完全复刻这套流程，还有个容易被忽略的收尾动作：提交前在 Linux 的终端里跑一遍bash scripts/check.sh，检查 JSON 语法、缺失文件、密钥是否泄漏。我吃过亏就明白了——交上去的压缩包打不开，再好的功能也等于零。把这一步养成习惯后，我几乎没再遇到“代码在别人电脑上跑不起来”的情况。希望这套经过完整 Linux 工作流的记忆仓库方案，能帮你在课程设计答辩时少一点手心冒汗，多一分从容。

本文还有配套的精品资源，点击获取