hello-world

后端接入deepseek的api

由于deepseek-v3提供了openai相同的api格式，所以首先安装openai库

1
npm install openai

接下来，请求api

1
2
3
4
5
6
7
8
9
10
11
12
const openai = new OpenAI({
    baseURL: 'https://api.deepseek.com',
    apiKey: '你的apikey'
});
const completion = await openai.chat.completions.create({
    messages: messages, //对话内容
    model: "", // 有三个模型，"deepseek-reasoner", "deepseek-chat", "reasoner"
    stream: true
});
for await (const chunk of completion) { 
 // 即可获取到返回的内容
})

出塞二首·其一

## 明月照彻千年关隘：王昌龄《出塞》的时空咏叹

“秦时明月汉时关”，这七个字如青铜编钟的轰鸣，在历史长河中震荡出苍茫回响。王昌龄以诗人的敏锐捕捉到华夏文明永恒的困境——绵延千年的边塞烽烟，在七绝的方寸之间构建起横跨秦汉的时空剧场，让盛唐的明月照亮了每一个时代的边关。

一、时空镜像中的永恒叩问
首句的”秦时明月汉时关”绝非简单的景物罗列，而是诗人精心设计的时空蒙太奇。当秦砖汉瓦在月光下泛着冷辉，征人的白骨早已化作泥土，但边关的箭楼依然矗立。这种互文见义的手法，将秦汉的烽火台与盛唐的戍楼叠印，在月光的穿透下显影出历史惊人的相似性。明月作为永恒的见证者，目睹了卫青的铁骑踏碎匈奴王庭，也凝视着哥舒翰的旌旗横绝青海。诗人用凝固的意象消解了时间的线性，将边塞的宿命感推向永恒。

二、悲怆史诗里的人性光芒
“万里长征人未还”如一声穿越时空的叹息，在苍茫大地上回荡。诗人以白描手法勾勒出人类战争史上最悲壮的剪影：从秦代征发的刑徒到汉代戍边的士卒，从盛唐远征的府兵到明代屯守的军户，无数生命化作边关的沙粒。但在这血色长卷中，人性的光芒始终闪耀。玉门关外的羌笛里飘着江南的柳色，燕然山上的石刻中藏着士卒的乡愁，诗人用最克制的笔触，将个体生命的温度熔铸进历史的铁幕。

三、英雄神话的精神突围
“但使龙城飞将在”的呼唤，是民族集体记忆的精神图腾。李广的箭镞、卫青的长剑、霍去病的金甲，在诗歌中凝结为抵御外侮的精神符号。这种对英雄的追慕，实则是对现实的深刻反讽——当开元盛世的边将沉迷于虚报战功，当戍卒的鲜血成为权贵的勋章，诗人用历史的明镜照见现实的荒诞。英雄神话的建构，既是对庸将误国的辛辣批判，更是对民族尚武精神的深情招魂。

在丝绸之路的驼铃与烽火台的狼烟交织处，王昌龄完成了对华夏文明的深度书写。这首七绝超越了具体的时空局限，将边塞诗推向了哲学的高度。当我们今天重读”不教胡马度阴山”，不仅听到金戈铁马的铿锵，更能触摸到文明存续的深层密码——在永不停息的冲突与融合中，那个关于守卫与开拓、牺牲与传承的永恒命题，依然在历史的天空下回响。

hello-world

微信支付商户证书

步骤一：登录商户平台，进入平台证书管理
1.先进入【账户中心-API安全】，下载工具，申请证书。
2.设置APIV3密钥。
登录微信支付商户平台，进入【账户中心-API安全-平台证书】，点击“管理证书”。

hello-world

Markdown 格式

1.代码格式

点击️链接

2.代码格式

1
2
3
4
5
6
7
8
9
10
11
import { Controller, Get } from '@midwayjs/core';

@Controller('/')
export class WeatherController {
  // 这里是装饰器，定义一个路由
  @Get('/weather')
  async getWeatherInfo(): Promise<string> {
    // 这里是 http 的返回，可以直接返回字符串，数字，JSON，Buffer 等
    return 'Hello Weather!';
  }
}
hello-world

生成ios应用证书

使用OpenSSL生成私钥和证书申请文件

1.生成证书申请文件的前提是生成私钥，因此需要先用以下命令生成私钥文件：

1
openssl genrsa -out adp.key 2048

adp.key是生成的私钥的文件名，可以替换成实际需要的名字，建议使用.key作为后缀名。如果已有私钥文件，可以跳过这一步，私钥文件可以重复使用不需要每次都重新生成。

使用上一步中生成的私钥文件生成证书申请文件：

1
openssl req -new -key adp.key -out adp.csr

adp.key是第1步中生成的私钥文件的文件名，请根据实际情况传入。

adp.csr是生成的证书申请文件，可以替换成实际需要的名字，建议使用.csr作为后缀名。

在输入命令后，如下图所示，请根据命令提示和实际情况输入这些信息

输入完毕后证书申请文件就生成好了。生成的证书申请文件可以重复使用不需要每次都重新生成。

3.生成的证书申请文件可以直接在苹果开发者网站上用于申请开发、发布、推送等各类证书，在需要的地方根据提示直接上传即可。需要注意的是私钥文件和证书申请文件都可重复使用，且私钥文件在后续生成.p12证书时仍需用到，因此请妥善保管这两个文件。

苹果开发者网站
1.先生成Identifiers证书标识
2.然后Profiles生成，下载development.cer

使用OpenSSL生成.p12格式的证书
1.在苹果开发者网站上下载证书文件，并将证书文件与申请时所用证书申请文件对应的私钥文件放到同一目录。
2.由于OpenSSL的PKCS封装子命令不能直接支持苹果网站上下载的.cer证书格式，因此需要使用以下命令对证书格式进行转换：

1
openssl x509 -inform der -in development.cer -out development.pem

development.cer是从苹果开发者网站上下载的证书文件名，请替换成实际的名字

development.pem是转换成.pem格式后的证书文件名，可以替换成实际需要的名字，建议采用.pem作为后缀名。

3.基于私钥文件和证书文件输出.p12文件：

1
openssl pkcs12 -export -clcerts -in development.pem -inkey adp.key -out adp.p12

development.pem是从苹果网站下载并转换成pem格式后的证书文件名，请替换成实际的名字。

adp.key是申请证书时上传到苹果网站的证书申请文件对应的私钥文件名，替换成实际的名字。

adp.p12是最终生成的.p12证书文件名，可以替换成实际需要的名字，建议采用.p12作为后缀名。

输入命令后根据提示输入密码并确认密码后相应的证书文件就生成好了。

经过验证生成的证书文件可以正常导入苹果“钥匙串”应用，也可正常用于开发、发布、APNs对接等场景。

fetch流式


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
async function processStream() {
  const response = await fetch('你的流式接口地址');
  const reader = response.body.getReader();
  const decoder = new TextDecoder('utf-8');
  let buffer = '';

  while (true) {
    const { done, value } = await reader.read();
    if (done) break; // 流结束

    // 将二进制数据转换为字符串并追加到缓冲区
    buffer += decoder.decode(value, { stream: true });

    // 按换行符分割缓冲区
    const parts = buffer.split('\n');
    
    // 保留未处理的部分（最后一个元素可能不完整）
    buffer = parts.pop() || '';

    // 处理每个完整的 JSON 对象
    for (const part of parts) {
      if (part.trim() === '') continue; // 跳过空行
      try {
        const json = JSON.parse(part);
        console.log('收到独立 JSON:', json);
      } catch (err) {
        console.error('解析 JSON 失败:', err);
      }
    }
  }

  // 处理缓冲区剩余内容（如果有）
  if (buffer.trim() !== '') {
    try {
      const json = JSON.parse(buffer);
      console.log('最后一条 JSON:', json);
    } catch (err) {
      console.error('解析末尾 JSON 失败:', err);
    }
  }
}

// 调用函数
processStream();

关于系统跨日处理

在酒吧的下单系统中，营业时间从每日21:00至次日5:00，且每个营业日归属于开始日期（例如10月1日的营业时间段为21:00至10月2日5:00）。系统按营业日划分日期，而非自然日。

问题解析：

时间归属逻辑：

若客人在凌晨2点（例如10月2日2:00，属于10月1日营业日）下单，预定“当天晚上10点”的桌台，这里的“当天”需明确归属：

凌晨2点仍属于前一日的营业日（10月1日营业日）。

而“晚上10点”实际属于下一营业日（10月2日营业日，21:00至10月3日5:00）。

系统显示逻辑：

预定记录会保存在目标营业日（10月2日）的桌台状态中。

当用户选择查看10月2日的日期时，系统会显示该桌台在22:00的预定信息。

若查看10月1日的日期，则不会显示此预定，因其属于下一个营业日。

结论：
该预定将显示在下一个营业日（下单日期的次日）的桌台状态中。用户需在系统中选择对应的次日日期（例如10月2日），方可看到该桌台当晚10点的预定信息。