持续更新优化，部分内容太过基础没写
Java概述程序：计算机执行某些操作或者解决某个问题而编写的一系列有序指令的集合
Java诞生与1995年 作者 扎姆斯高斯林
Java技术体系平台
Java SE 标准版 桌面应用
Java EE 企业版 Web应用 主要学习这个
Java ME 小型版 移动应用和嵌入式
Java重要特点
面向对象 oop
语言健壮
跨平台
解释型语言 需要解释器
Java虚拟机 JVM用于在不同的设备上运行.class字节码文件，屏蔽系统差异
JDK、JREJDK java开发工具包 Java Development Kit 开发者用
JDK=JRE+java开发工具
JRE java运行环境 Java Runtime Environment 普通用户用
JRE=JVM+Java核心类库
注意事项
文件名必须与public类名一致
一个源文件中最多只能有一个public类
编译之后每一个类对应一个.class文件
Java语言严格区分大小写
每个语句以 “;” 结束
java 命令之后跟类名
main 方法就是 J ...
今天安装openclaw对接qq机器人遇到了一个问题，直接运行
openclaw plugins install @tencent-connect/openclaw-qqbot@latest
这个脚本，会出现下面这个提示
npm install failed:
npm 安装依赖失败，尝试了很多次都会提示这个(之前运行这个脚本就没遇到这个情况，很玄学) 。
经过了一天的折腾，找到了问题所在和解决方案
问题核心原因1. OpenClaw 内置安装机制的「过度限制」OpenClaw 的 plugins install 命令不是简单调用 npm install，而是加了多层校验：
检测插件代码中的 child_process（Shell 执行）、环境变量读取等行为，即使是插件正常功能，也会触发「安全拦截」；
内置的 npm 执行环境被限制了权限 / 超时时间，一旦依赖下载稍慢或编译耗时，就会直接判定「npm install failed」；
临时目录（/tmp/openclaw-plugin-*）的权限 / 生命周期管控严格，手动操作稍慢就会被自动清理。
2. 服务器基础环境不匹配
Nod ...
学习心得
未读一、比特币的诞生2008 年，一位化名中本聪的神秘人物（或组织）发表了比特币白皮书，提出一种去中心化的数字货币构想，旨在实现无需传统金融机构的交易体系。次年，即 2009 年，中本聪基于白皮书中的理念，开发出比特币钱包软件，并公开供用户下载使用，比特币网络由此正式启动。
二、比特币网络搭建当新用户下载并运行比特币钱包软件时，软件会自动连接内置的种子节点。这些种子节点如同网络的 “联络站”，会向新用户节点分享其已连接的其他节点信息。新用户节点借此与众多对等节点建立起 P2P（点对点）连接。在这个过程中，各个节点按照既定规则相互交换信息，逐渐构建起一个没有中心控制的比特币网络。网络中的所有节点地位平等，共同维护着网络的正常运转。这种 P2P 网络结构确保了比特币系统的去中心化特性，没有任何一个节点能够单独掌控整个网络。
三、钱包地址生成每个用户都可以通过本地的比特币钱包软件生成独一无二的钱包地址。钱包地址类似于现实生活中的银行账号，是用户在比特币网络中接收和存储比特币的标识。它由钱包软件依据特定算法生成，整个生成过程无需依赖第三方机构，极大地保障了用户的自主性和隐私性。这意味着用户可以完全 ...
HTTPS页面请求HTTP接口失败？一文讲透Mixed Content
前端开发中，有一个高频踩坑场景：前端绑定域名后，HTTP 协议下请求后端 IP 接口一切正常，可一旦开启 SSL 切换为 HTTPS，接口就直接请求失败，控制台报出红色错误 —— 这不是代码 Bug，而是浏览器的安全限制，核心原因就是「Mixed Content（混合内容）」。
一、先明确核心概念：Mixed Content（混合内容）首先厘清两个基础认知，避免混淆：
HTTPS 的本质
HTTPS = HTTP + TLS（Transport Layer Security，传输层安全协议），相当于给 HTTP 传输的数据加了一层加密外套，防止数据被窃听、篡改，保障访问安全；而 HTTP 是明文传输，无任何加密保护。我们常说的「开启 SSL」，本质就是启用 HTTPS 加密。
Mixed Content（混合内容）的定义
当 HTTPS 加密页面 中，请求了 HTTP 明文资源 时，就属于 Mixed Content（混合内容）。
浏览器的安全逻辑：HTTPS 页面代表用户处于安全的加密环境，若此时请求 HT ...
阿里云大模型工程师ACA认证学习笔记背景知识从2022年底ChatGPT的一鸣惊人，再到持续进行的”百模大战”，”大模型”已经逐渐成为了技术和公众领域的热点。
大模型是人工智能领域的一个重要里程碑，它推动了人工智能技术的发展，并为人类的未来带来新的可能性。有人曾经类比，大模型的发明相当于人类文明的哪个节点？一个浪漫的答案可能是：人类学会使用火的时刻。
人工智能定义：人工智能（AI）是一门使机器模拟人类智能过程的学科，其中具体包括学习、推理、自我修正、感知和处理语言等功能。人工智能涉及计算机科学、数据分析、统计学、机器工程、语言学、神经科学、哲学和心理学等多个学科的领域，旨在研究、设计、构建具备智能、学习、推理和行动能力的计算机和机器。
分类
机器学习(ML)：研究计算机如何在没有明确编程的情况下，通过对数据的分析、学习，自动改进其行为或做出预测的学科。旨在使计算机系统具备从经验中学习的能力，以适应新情况、解决问题或完成特定任务。
根据工作模式分类：
监督学习：学习为人提供的数据，对具备某种特征的数据进行人为标记。
无监督学习：根据数据特征进行相似归类。
强化学习：奖励机制，猜对了奖励 ...
参考：https://tailscale.com/blog/how-nat-traversal-works
一、相关工具（含使用场景）
在线检测NAT类型：NAT Checker（核心功能：检测映射/过滤行为，精准判定NAT1-9类型，建议打洞前必测）
通用打洞工具：Tailscale（适配EasyNAT全场景，HardNAT需依赖UPnP，操作简单，适合新手）
复杂NAT适配工具：Easytier（支持端口扫描/预测，可尝试HardNAT组合，适合进阶用户）
辅助排查工具：Wireshark（抓包分析流量走向，定位打洞失败原因，如端口过滤、映射端口变化）
二、必备知识（打洞原理基础）路由器通过两张核心表实现NAT管控，这是打洞能否成功的关键：
NAT映射表：记录内部主机（内网IP:端口）与公网（公网IP:端口）的映射关系，仅当内部主机向外发起请求时生成/更新；
状态表：记录内部主机的对外请求状态（如请求目标IP:端口、连接状态），仅当外部流量与状态表匹配时，才允许穿透NAT进入内网。
打洞的核心逻辑：通过中转服务器交换双方公网映射信息，再主动发起请求触发对方状态表更新，让后续流 ...
用过 Vercel 的开发者大概都对它的便捷性印象深刻 —— 将 Node 项目推送到 GitHub 后，几分钟内就能自动构建部署并提供访问服务，免费计划也足够日常折腾。但随着 Vercel 域名 DNS 污染越来越频繁，不挂梯子几乎无法访问，好好的免费资源就这么闲置了实在可惜。于是我尝试用腾讯云 EO（EdgeOne）对其进行加速，过程中踩了个典型的坑，最终摸索出解决方案，特此记录分享给有同样需求的朋友。
一、踩坑现场：自信配置却遭遇 522 死循环核心诉求很明确：利用腾讯云 EO 的免费计划，解决 Vercel 域名访问受阻的问题。我想当然地认为加速配置的关键就是 “回源 Host 填写 Vercel 提供的默认域名（如 xxx-project.vercel.app）”。
按照这个思路配置完成后，满心期待地等待部署结束，结果访问时直接弹出 522 错误 —— 服务器无响应。反复检查配置参数、重新部署项目，甚至更换网络环境测试，522 错误始终如影随形，完全摸不着头脑。
二、问题本质：多层 CDN 嵌套导致回源失效我翻了一圈 CDN 加速的核心原理文档，再结合 Google 到的案例 ...
在数据查询场景中，“如何高效呈现大量数据” 是开发者绕不开的问题。分页作为解决 “数据量过大导致的内存溢出、响应缓慢” 的核心手段，主要分为数据库分页（数据库端过滤 + 限制返回条数）和程序分页（全量查询后内存中分片）两种实现方式。
很多开发者在选型时会陷入纠结：到底该让数据库 “多干活”，还是让应用程序 “扛压力”？其实两者没有绝对优劣，核心取决于数据量、业务复杂度、实时性要求等关键因素。本文将从原理、场景、优缺点、实操建议四个维度，帮你彻底理清选型逻辑，避免踩坑。
一、先搞懂：两种分页的核心原理在深入选型前，我们需要先明确两种分页的本质区别 ——数据过滤和分片的 “执行位置” 不同。
1. 数据库分页：数据库端 “按需取数”数据库分页的核心是让数据库只返回当前页需要的数据，通过 SQL 语法（如 LIMIT/OFFSET、ROW_NUMBER()）或条件过滤，在数据查询阶段就完成 “筛选 + 分片”，最终只将单页数据（如 10 条、20 条）返回给应用程序。
典型实现示例：
MySQL：SELECT * FROM orders WHERE status = 1 ORDER BY ...
部署后浏览器从「根目录（/favicon.ico）」获取图标，而非你设置的 static/favicon.ico，核心原因是 浏览器的默认行为 + 配置 / 引用缺失，具体拆解和解决步骤如下：
一、核心原因：浏览器的「默认 /favicon.ico 请求」这是最根本的原因 ——浏览器会自动向网站根目录发送 /favicon.ico 请求，无论你是否在页面中引用：
即使你在 <head> 中写了 <link rel="icon" href="/static/favicon.ico">，部分浏览器（如 Chrome、Edge）仍会先尝试请求 /favicon.ico（根目录），失败后才会使用你指定的路径；
部署环境中，若根目录没有 favicon.ico，且你的页面引用有问题（如路径错误、缓存），就会出现「图标不显示，Network 面板看到 /favicon.ico 404」的现象。
二、其他辅助原因（部署环境常见）
页面引用路径错误：
本地开发时 url_for('static', filename= ...
在使用腾讯云 EdgeOne 海外节点加速海外业务时，很多开发者会遇到一个核心问题：Nginx 日志中记录的是 EdgeOne 节点 IP 而非用户真实 IP，导致无法进行用户行为分析、地域统计和异常访问拦截。本文将从「问题原理」「手动配置」「自动化更新」「故障排查」四个维度，提供一套适配 Nginx + 宝塔面板的完整解决方案，新手也能快速上手。
一、核心原理：为什么需要特殊配置？当用户访问经过 EdgeOne 加速的网站时，请求会先经过 EdgeOne 海外节点（反向代理），再由节点转发到源站 Nginx。此时 Nginx 会默认将「直接连接的客户端 IP」（即 EdgeOne 节点 IP）识别为用户 IP，而非真实的用户公网 IP。
解决思路的核心是「信任代理」：
EdgeOne 节点会在转发请求时，通过 X-Forwarded-For 头携带用户真实 IP（格式：用户真实IP, 节点IP1, 节点IP2）；
配置 Nginx 信任所有 EdgeOne 节点 IP，让 Nginx 从 X-Forwarded-For 头中自动跳过节点 IP，提取最原始的用户真实 IP。
关键 ...
