WSL解决内网和windows不共享

📝 Windows + WSL2 端口转发教程(访问 Flask 5000) 前提条件 你正在使用 WSL2(Ubuntu 或其他 Linux 发行版) Windows 主机能访问局域网(Wi-Fi 或以太网) Flask 服务在 WSL2 中运行,并监听: app.run(host="0.0.0.0", port=5000) ⚠️ host="0.0.0.0" 必须,否则外部无法访问 第 1 步:确认 WSL2 的 IP 在 WSL2 中运行: ip addr show eth0 你会看到类似: inet 172.26.209.37/20 记下 inet 后面的 IP(本例是 172.26.209.37),这是 WSL2 内部 IP。 第 2 步:打开 PowerShell(管理员模式) 按 Win + X → 选择 Windows PowerShell (管理员) 确认管理员权限,必要时允许 UAC 提示 第 3 步:设置端口转发 在 PowerShell 中执行以下命令,将 Windows 的 5000 端口转发到 WSL2: ...

2025年10月22日 · 2 分钟 · map[name:Jeanphilo]

局域网Git Bare

在局域网访问 Windows WSL2 上的 Git Bare 仓库 在开发中,我们经常需要在多台电脑之间共享 Git 仓库。如果你在 Windows 上使用 WSL2,并且想在同一局域网的其他电脑访问 WSL2 上的 Git bare 仓库,本文将一步步教你实现。 1. 在 WSL2 创建 Git Bare 仓库 打开 WSL2 终端,进入你想存放仓库的目录,执行: git init --bare my_project.git my_project.git 是 bare 仓库,不含工作区,仅用于推送和拉取。 bare 仓库就像远程仓库一样,可以被克隆和操作。 2. 配置 WSL2 的 SSH 服务 为了让其他电脑访问仓库,需要通过 SSH 访问 WSL2。 安装 SSH 服务: sudo apt update sudo apt install openssh-server -y 启动 SSH 服务: sudo service ssh start 检查 SSH 服务状态: sudo service ssh status 默认端口是 22,可以在 /etc/ssh/sshd_config 修改。 3. 获取 WSL2 IP 地址 在 WSL2 终端运行: ...

2025年10月22日 · 2 分钟 · map[name:Jeanphilo]

如何使用wrk进行压测

🚀 使用 wrk 对接口进行高性能压力测试(超详细教程) 本文介绍如何在 Ubuntu 环境中使用 wrk 对后端接口(如 Flask / FastAPI / Spring Boot 等)进行高并发压力测试,并结合结果分析性能瓶颈。 🧰 一、什么是 wrk? wrk 是一个现代化、高性能的 HTTP 压测工具,由 C 语言编写,具有以下特点: 高并发能力强:支持成千上万的并发连接 支持多线程:充分利用多核 CPU 可自定义 Lua 脚本:适合复杂场景(如自定义请求头、Body、Token 等) 比 Apache Benchmark (ab) 更轻量、更快、更稳定 ⚙️ 二、安装 wrk 在 Ubuntu / Debian 上安装: sudo apt update sudo apt install wrk -y 验证安装是否成功: wrk --version 输出类似: wrk 4.2.0 [epoll] 表示安装成功 ✅ 🧪 三、快速开始压测 假设你的服务运行在: http://192.168.1.224:5000/api/tenders 运行: wrk -t4 -c100 -d30s http://192.168.1.224:5000/api/tenders 参数说明: 参数 含义 -t4 启动 4 个线程(利用多核 CPU) -c100 模拟 100 个并发连接 -d30s 持续压测 30 秒 最后一个参数 目标 URL 📊 四、示例输出结果解读 假设输出如下: ...

2025年10月22日 · 2 分钟 · map[name:Jeanphilo]

git分支管理方法

🌿 简化 Git 分支工作流(个人 / 小团队) 本工作流基于 Git Flow 精简而来,适合个人或小团队,既规范又不复杂。 🚀 1. 主分支(长期分支) main 永远保持稳定、可发布的状态。 部署到生产环境的代码都来自这里。 对于小团队,通常只需要 main,不需要维护 develop。 🛠️ 2. 功能开发(Feature Branch) 分支命名:feature/<功能名> 用途:开发新功能,完成后合并回 main。 示例: feature/login-api feature/user-profile 流程: # 从 main 创建功能分支 git checkout -b feature/login-api main # 开发完成后,合并到 main git checkout main git merge feature/login-api git branch -d feature/login-api 🐞 3. Bug 修复(Bugfix Branch) 分支命名:bugfix/<问题名> 用途:修复测试或开发环境的 bug。 示例: bugfix/fix-login-redirect 流程同 feature 分支,完成后合并回 main。 🔥 4. 紧急修复(Hotfix Branch) 分支命名:hotfix/<问题名> 用途:生产环境出现严重问题时的快速修复。 示例: ...

2025年10月20日 · 1 分钟 · map[name:Jeanphilo]

在本地使用git裸仓库实现开发环境和测试环境隔离

在本地使用 Git 裸仓库实现开发环境和测试环境隔离 在全栈开发的过程中,我们常常遇到一个问题:开发环境和测试环境如何隔离? 很多人第一反应是用 GitHub 或 GitLab 来托管代码,但如果项目涉及隐私,不方便放在公共仓库,那该怎么办呢? 其实,Git 是分布式的,我们完全可以在 本地电脑上建立一个“裸仓库 (bare repo)”,当作“远程仓库”来用,从而实现 开发环境 → 测试环境 的代码迁移和同步。 什么是裸仓库 (bare repository) 普通 Git 仓库(git init)包含 工作区 + .git 元数据,可以直接编辑文件。 裸仓库(git init --bare)只有 Git 的版本信息,没有工作区,不能直接编辑文件,通常作为 远程仓库 来存储和同步代码。 简单理解: 开发仓库:我在这里写代码。 裸仓库:我用来存放代码历史,作为远程同步点。 测试仓库:从裸仓库克隆出来,模拟运行环境。 步骤一:创建裸仓库 在本机某个目录(比如 ~/.repos)下创建裸仓库: mkdir -p ~/.repos cd ~/.repos git init --bare scrapy.git 这样你得到一个路径 ~/.repos/scrapy.git,它就是本地的远程仓库。 步骤二:在开发仓库里添加远程 假设你的开发仓库在 ~/scrapy: cd ~/scrapy git remote add local ~/.repos/scrapy.git 检查一下远程是否添加成功: git remote -v 输出类似: local /home/gong/.repos/scrapy.git (fetch) local /home/gong/.repos/scrapy.git (push) 说明配置成功。 ...

2025年10月20日 · 1 分钟 · map[name:Jeanphilo]

结构化日志和追踪

Python 日志与追踪 Python 日志追踪实践 结构化日志与追踪 副标题/摘要: 结合 logging + OpenTelemetry 实现结构化日志并把 trace_id 注入日志,便于在生产环境串联调用链与定位问题。 TL;DR: 设置 json 格式日志并通过 OpenTelemetry 在每条日志里注入 trace_id/span_id。关键步骤:安装依赖 → 配置 logging(JSON)→ 配置 TracerProvider → 用 Filter 从当前 span 提取 trace 信息并添加到日志记录中。 目录 背景与动机(为什么需要) 关键概念与术语解释 环境与依赖(安装命令) 逐步实战示例(可直接运行) 原理与实现要点 常见问题与注意事项 最佳实践总结 结论与下一步建议 可视化建议 参考与延伸阅读 可复制示例代码 背景与动机(为什么需要) 现代后端服务分布式部署后,单靠文本日志很难把一次请求链路从入口到后端串起来。结构化日志(JSON)便于聚合与查询;而分布式追踪(tracing)给出调用链与 span 信息。二者结合能快速定位延迟与错误根因:日志告诉你“发生了什么”,trace 告诉你“这个请求经过了哪些服务/操作”。 关键概念与术语解释(简明) 日志(Logging):程序运行时的事件记录,通常按级别(INFO/ERROR)输出。 结构化日志:以 JSON 等结构化格式输出,便于机器处理与检索。 Trace/Span:一次分布式操作(trace)由若干子操作(span)组成,span 含有 trace_id 与 span_id。 Context Propagation:在不同服务/线程/协程中传递 trace context 以串联调用链。 环境与依赖(列出安装命令) 推荐环境:Python 3.8+ 安装依赖: pip install python-json-logger opentelemetry-api opentelemetry-sdk ...

2025年8月28日 · 3 分钟 · map[name:Jeanphilo]

如何使用和配置typescript环境

Introduction 对于typescript以.ts为后缀的文件,我们是不能直接编译运行的,我们需要把typescript文件转译为js文件然后再进行运行 我们可以选择两种方式,把ts文件传到服务器上使用ci工具进行编译,或者直接在本地转译后上传js文件到生产环境,如果我们想要在开发环境中直接进行运行测试的话,可以使用ts-node进行运行,但是开发环境之中还是需要编译

2025年8月28日 · 1 分钟 · map[name:Jeanphilo]

关于ai助手前端界面的新构建方案构思

Introduction 我现在想要构建一个可以树状,或者图状进行问答的ai系统,而不是传统的单线式对话流程 探索 开源框架探索 flowise

2025年8月27日 · 1 分钟 · map[name:Jeanphilo]

mastering paper

如何尽可能掌握一篇论文中的所有知识 结论 我们要真正"掌握"一篇论文,不是读一遍就行,而是按照现有结构把论文进行拆解,验证,重构并把关键点转化为你自己的表述或者实现.目标是:可以在5分钟内讲清楚核心贡献,可以手推关键公式,可以实现并复现一个核心实验 原理和背景 论文是作者对问题的压缩表达:省略背景、实验细节、直觉和失败。要掌握,需要把这种高密度信息“解压”回你自己的知识网络:理解背景假设、数学推导、工程实现、以及结论的适用范围。这样才能判断什么时候能用,什么时候不能用,什么时候要改进。 具体步骤 不要把论文当成“权威”,把它当成一个可以测验的主张:把声明分解成可验证的小断言,然后去验证它。掌握不是记住论文的文字,而是把它变为你自己能用的工具。不要偷懒 — 真正的理解需要做事:推导、实现、对比、解释。现在就挑一篇,按上面的三天计划开始。 准备与预读(30–60 分钟) 读题目、摘要、结论、图表(不必细读正文)。目的:抓住“这篇论文到底解决了什么问题、给出了什么结果”。 快速扫一遍引言和贡献列表,记录作者声称的三个关键点。 检查参考文献,确定是否需要补读哪些基础材料(比如某个经典算法或证明)。 精读(2–6 小时) 逐段细读方法/理论部分。遇到公式,尝试手推关键推导(用纸和笔)。 把每个重要符号写成表格,免得混淆。对算法,写伪代码。 标注不理解/可疑的地方,形成问题清单。 解构与重构(半天到几天) 把论文分解为:问题定义、关键假设、方法/算法、主要定理、实验设置、结论与限制。 为每一部分写一段 2–3 句的“我能讲给同领域的人”的解释(用你自己的话)。 将算法实现为最小可运行版本(See 实现建议)。 实现与复现(几小时到几天) 优先实现最能体现贡献的部分(一个算法/一个模型/一个关键实验)。 用小规模合成数据先做调试,再跑论文的设置。 必要工具/模板示例: 推荐环境:Python + Jupyter/Colab,或 C++/Rust(如果是系统/性能论文)。 常用库:numpy/pandas/matplotlib/scikit-learn/torch/tensorflow。 示例:把论文算法写成 Python 函数(伪代码转实现)。 逐行注释已写在函数 docstring 和代码中。把论文中的符号映射到代码变量,记录在注释里。 绘图与结果对比 重现关键图表(训练曲线、误差表)。如果不能一次跑出论文结果,先验证趋势和相对对比(例如比基线高多少)。 加入断言和单元测试:例如,对已知问题(合成数据)的行为应与理论一致。 消化与输出(持续) 把关键点写成一页“cheatsheet”或一篇短博客,目标:在五分钟内让人理解。 将难点做成 Anki 卡片(问题:关键假设、定理条件、公式推导步骤)。 尝试解释给陌生人或写读书报告。 工具推荐(实操) 文献管理:Zotero / Mendeley 笔记与知识库:Obsidian / Notion / org-mode 代码与实验:Git + Jupyter/Colab + Docker(必要时复现环境) 文本处理:pdftotext、pdfgrep、grep、ripgrep 常见错误 错误:只读不做(只看结论,不推导、不实现)。 调试:强制自己实现或至少写伪代码并手推一遍。 错误:忽视假设/边界条件(在不满足假设的地方直接使用方法)。 调试:列出所有假设,构造违反假设的测试用例,观察失败模式。 错误:把作者的实现等同于论文中的方法(代码细节、超参常被省略)。 调试:阅读作者代码(如开源),比对论文描述,记录差异。 错误:过早追求论文结果的数值精确复现。 调试:先验证可复制的趋势,再逐步细化超参/实现细节。 错误:数学推导只看结论公式,未验证每一步是否合法。 调试:逐行手推,找出隐含步骤或引用的引理,补读来源。 验证方法 能在五分钟内口述论文的核心贡献、适用场景与限制(不看稿)。 能手动推导关键公式或重写证明的主要步骤(纸笔完成)。 能实现一个最小工作例子,得到与论文一致的趋势或数值(至少在合成数据上)。 能回答以下问题:作者的关键假设是什么?结果如何依赖这些假设?有哪些潜在失败模式? 能把论文的想法应用到一个稍有不同的问题上并观察结果(迁移能力)。

2025年8月26日 · 1 分钟 · map[name:Jeanphilo]

如何创建mermaid图像并进行编辑

Introduction Mermaid是一个用于使用代码创建图像的框架,今天的博客,我们将会简单介绍如何在自己的服务器上安装相关的框架,并对代码进行渲染生成图像 具体步骤 如何安装渲染框架 使用 npm install -g @mermaid-js/mermaid-cli 就可以安装 需要注意的是该框架使用的npm版本需要大于20,所以我们需要切换npm版本,推荐使用nvm管理npm的版本 如果没有nvm的话,使用下列命令进行安装 curl -o https://raw.githubusercontent.com/nvm-sh/nvim/v0.39.4/install.sh | bash 然后对shell进行重启 然后使用 nvm install 20 nvm use 20 nvm alias default 20 进行安装,并把默认npm切换为20 可以使用 node -v npm -v 确认版本 如何进行渲染 将需要渲染的代码放置在以.mmd结尾的文件中 然后使用 mmdc -i diagrams/example.mmd -o images/example.svg 即可

2025年8月26日 · 1 分钟 · map[name:Jeanphilo]