这几年乱七八糟的学了很多东西，也做了好几个产品。没有一样学得好的，也没有一样做得成功的。

学习方面，初级与中级会计师考试是通过了，但实际上很多知识点仍然处于模糊状态。AI方面的学习则毫无进展，始终停留在基础入门阶段，没有做出过什么实际有用的东西。英语马马虎虎4级水准，离流畅阅读与听力相差甚远。

而在工作上，做了进销存软件，付费用户没几个。做了会计软件（半成品）。做了一个学习辅助小程序，用户倒是有一批，但是没有恰当的变现方式，目前也处于半放弃状态。

细细总结，主要就是不够专注，没有一心一意的做好一件事。人的精力是有限的，同时关注太多的事，无论是学习还是工作，如果三心二意的，就很难有所成。

所以2025，给自己定个计划。在学习上花3-6个月的时间提高自己的英文能力，达到流利阅读与沟通的能力（国内的机会太少，管得也太紧，也许走向海外才有更多的机会）；英文能力满足要求后，再深入的去学习AI相关的应用。而在工作上，一心一意的做好会计软件，以我现在养的几个群，应该能吸引到用户，走免费软件+广告的路子试试看；学习辅助小程序则直接放弃吧（受到平台的限制，很多变现模式没法用）；至于进销存，仍然需要做好维护工作，毕竟还是有点用户的。

无论年龄多大，我对未来总是充满期待，不抛弃不放弃。加油2025！

一个朋友自己注册了一个小公司赚点外快，今天找我说是因为前面增值税申报对比不符，系统被锁开不了票。我查询后发现，开票记录的税额是323.31，但是申报系统里算出来是323.30（且不能手动更改）。我猜申报系统里可能是用总额乘以税率得出的，所以才会存在这么个分币误差。

当然最后通过在线客服咨询得知，开不了票其实是因为以前的税盘没有缴销，让带上空白发票、公章、税盘去缴销就行。但这个分币误差却又确实存在，不知道实际扣款时扣的是多少。我挺好奇他的那个代账会计难道没发现这个误差吗？

就我个人体验而言，国内政务系统最好用的可能就是税务系统了，客服响应真的快，在线解决问题。至于分币误差和提示不够精准其实都是小问题，只要响应迅速，这些问题都不算问题。

在postgresql数据库中，默认情况下所有字符类型的字段都是区分大小写的，但在实际业务中我们一般需要不区分大小写。这就导致需要不区分大小写的查找，在写sql语句时需要做大小写转换。最为麻烦的是，索引也区分大小写，这使得具有unique属性的字段里会将’abc’、’Abc’、’aBc’视为非重复值，给数据的维护带来麻烦。虽然可以通过使用表达式索引解决，但这显然提高了复杂性。

最优的解决方案是使用citext类型。启用方式如下：
CREATE EXTENSION IF NOT EXISTS;

执行本命令后，会在当前search_path（一般默认是public）所指定的schema的type里新增一个类型，然后在建表时直接指定字段类型为”citext”即可。

这里需要注意的是：如果在其他schema里的表使用了citext类型，必须确保在执行查询前使得search_path指向的是type所在schema。写这篇文章就是因为我的一个数据库，删除了默认的search_path指向的schema(public)，创建citext扩展时类型写到了schema(main)中了。由于当前schema(public)不存在，在查询时使得使用了citext类型的字段仍然对大小写敏感，必须手动设置search_path为main之后，再查询才能正常发挥citext类型的大小写不敏感的特性。

一直在台式机上使用comfyui，毕竟台式机上有一个3060显卡。但每次画点小图就要开台式机也挺烦的。看到comfyui支持使用directml，就在笔记本上安装了一下。我的笔记本是AMD的CPU+集成显卡，没有独立显卡。安装过程倒是很顺利，唯一需要注意的是，应该先安装torch_directml，后再执行pip install -r requirects.txt，因为requirects.txt文件里的torch版本和torch_directml里的torch版本不一致。

第一次是在wsl中安装的，安装过程很顺利，但在执行pip install torch_directml时，我发现他下载的包中包含”cuda”字样，果不出所然，在出图时提示找不到nvidia驱动。后问AI得知，wsl中使用directml只支持nvidia的显卡，然后微软相关文档页面居然没给提说明。

第二次是在宿主机安装的，安装过程一如既往的顺利，也能顺利启动。然而在出图时，笔记本风扇狂转，然后直接死机了。盲猜，directml用是可以用的（因为测试示例代码是可以正常运行的，也能返回正确的结果），就是笔记本是轻薄本，散热压不住，直接挂了。

我在笔记本上运行comfyui的计划只能泡汤了，继续使用台式机出图吧。轻薄本带着是方便，但是散热确实不行。买笔记本还是应该买傻大黑粗的大家伙，至少散热强，如果散热足够强的话，笔记本上跑图应该没有问题。

以前一直用react.js写前端，最近一个项目使用了solid.js，发现一个我一直存在的误解。input的onchange事件只在内容被改变且input失去焦点时才会触发。react由于采用了一个叫作“合成事件”的机制，导致在react里input的onchange事件只要input内容发生变化，即使没有失去焦点也会立即触发。在原生写法和solid.js中不是这样的，onchange事件在内容发生变化时并不会触发，只有当input失去焦点时才会触发。这么一个小小的误解导致了我软件的bug。

更详细的解释由AI给出：

在 React 中，input 的 onChange 事件与传统的 HTML 行为不同。在 React 中，onChange 事件是在用户输入内容时立即触发的，而不是等到失去焦点时。

这是因为 React 使用了一个叫做 “合成事件”（SyntheticEvent）的机制来处理事件。合成事件是 React 自己实现的事件系统，它可以在不同浏览器之间保持一致的行为。

在 React 中，onChange 事件是通过 onInput 事件来实现的，这意味着当用户输入内容时，onChange 事件会立即被触发。

因此，在 React 中，你可以使用 onChange 事件来监听输入框的变化，而不需要担心它是否会在失去焦点时触发。

AI确实给我们的工作和生活带来了极大的方便。

今天把另几个域名都转了改用let’s encrypt的证书，但在使用nginx部署几个空网站时，nginx 报403 forbidden错误。经搜索发现是由于权限引起的，因为我的几个空网站使用的是index.html这样的静态文件，且放在我自己登录用户的home目录的，而nginx是使用www-data身份运行，所以他无权限访问我的home目录，也就出现了403 forbidden错误。解决方案也很简单，只要把www-data加入我登录的用户组就可以。因为用户home目录默认同组用户具有读权限。

下午这么几个空网站折腾了2个多小时，确实有点费时间，应该考虑使用podman部署的，至少以后迁移换服务器方便多了。

来源于知乎回答。有哪些思维透彻的历史书籍推荐？ - 商熵的回答 - 知乎

1.《南明史》，顾诚。举个例子：李自成败出北京并不是因为他入京以后迅速堕落腐化，而是相反，是因为他没有联合地主阶级完成封建化才导致的。类似于这样的观点，两册书俯拾皆是。虽然有些观点不能认同，但着实是极为优秀的作品，深入浅出，比读小说好看。

2.《党员、党权与党争 : 1924—1949年中国国民党的组织形态》，王奇生。我党对国民党的打击不是优势问题，是降维打击。

3.《被统治的艺术 : 中华帝国晚期的日常政治》， 宋怡明/ 钟逸明。以小见大的经典之作，老百姓如何与国家斗智斗勇。尤其是每一章节的“回目”，甚得我心。写的是被统治的艺术，书本身也是历史叙述的艺术。

4.《大汉帝国在巴蜀 : 蜀汉天命的振扬与沉坠》，饶胜文。虽然本书将政权合法性对于政治的影响提到很高的位置，部分论述有失偏颇，但是瑕不掩瑜，提供了一个认识大汉巴蜀的新视角。看完本书，方知书名的高妙。又读了一遍，蜀汉政治取向以及彼可取而代之的解读有新启发，连带着明白了一系例事情（比如为什么诸葛亮会感叹只有法正能劝刘备）

5.《民族与古代中国史》，傅斯年。非常薄的一本书，但分量可真不轻。尤其是夷夏东西说和五爵制，读来甚有启发。非专业的人读着也很好。

6.《这受难的国度 : 死亡与美国内战》，德鲁·吉尔平·福斯特。节奏明晰，观点明确，叙述有力，对内战的反思和研究角度新颖且不乏深度，很棒。

7.《中国上古史研究讲义》，顾颉刚。极为好看，通俗易懂，拍案叫绝。可以看一下我写的其中一部分内容整理。我把本书最难的部分整理成故事了，助力各位读东汉内容

8.《清代八股文》，邓云乡。八股文要是写好了，文章“鞭鞭见血”。

9.《论三国人物》，方诗铭。有些观点虽然不认同，但是瑕不掩瑜。其中有很多观点大胆又令人信服，真是读三国深入浅出的好书。

10.《中国古代国家的起源与王权的形成》，王震中。严谨厚实，深入浅出，对于国家、社会演进的内涵和外延分析的非常到位且很清晰，最后的结语高度凝练，观之甚服。

11.《《易经》释梦》，吴钢。另类解读易经，把易经当历史，结合甲骨文和古文献重新阐述商周革命的过程和结果。逻辑严谨性三星，故事张力说服力四星，思考猎奇程度五星。

开始部署时只想着简单不想引入太多的复杂性，所以直接部署在windows上了。但是现在用户并不多，所以选择足够便宜的云服务器就很有必要，每年服务器到期就有必要平衡一下费用情况，进行迁移。以目前的部署情况来看，迁移还是有点麻烦的，新换服务器应该充分考虑迁移的方便。

初步设想仍然使用windows主机，但是使用podman部署产品。虽然podman在windows上运行于wsl内（即windows运行linux，linux运行podman容器，套了3层娃），在性能上应该会有不小的损失。考虑到用户并不多，这点性能损失我认为是可以接受的（没作具体的评测，以我目前的用户数来说，我觉得评测性能损失是多此一举）。

整个系统分为：nginx容器(配置certbot更新let’s encrypt的证书)、postgre容器、服务入口容器（即main，用来根据url进入不同产品）、产品容器（每个产品分别一个容器，相互隔离）。每个容器配置一个卷用来作持久化存储。在windows层面将对本机80/443端口的访问转发给wsl的linux系统，再由linux系统将此映射到nginx容器。

如此部署后，换服务器时，只要 wsl --export将wsl子系统导出，在新的服务器中再wsl --import导入，即可完成部署，无需进行太多复杂的配置。当然这只是一个初步设想，应该还会有未考虑到的地方，只有提前走一遍完整的流程才能知道未知的缺陷。但这个做法应该是可行的。

2024-11-19新想法

其实完全没必要用podman，wsl本身就算是一个容器，将所有的服务都部署在wsl中就可以，需要更换服务器时，直接导出wsl即可。自己本机的开发环境也可以这样搞，这样重装系统就会方便很多，直接导出wsl镜像是多么方便的事。

linux下网络代理的设置

http代理

1
2

export http_proxy=http://127.0.0.1:8888
export https_proxy=http://127.0.0.1:8888

也可以使用socks代理

1

export all_proxy=socks5://127.0.0.1:8888

要注意的是当使用socks代理时，python需要安装pysock包，否则无法使用

这些设置可以直接添加在~/.bashrc文件中，以便于系统启动时自动使用代理，如果用在命令行里，则只对当前会话有效。

windows下网络代理的设置

windows下的代理设置分为传统cmd和powershell两种情况

传统cmd

1
2

set http_proxy=socks5://127.0.0.1:8888  
set https_proxy=socks5://127.0.0.1:8888

cmd这个也可以使用http代理，但这个设置放到powershell里是不起作用的

powershell

1
2

$env:http_proxy = "http://127.0.0.1:8888"
$env:https_proxy = "http://127.0.0.1:8888"

powershell里只支持http代理，设置成socks5://xxxx是不起作用的

ssh的一些解决网络问题有用的参数

-L 参数

1

ssh -L localhost:8787:remote1:9999 user@remote2

此命令可以将对本地8787端口的访问通过remote2映射到remote1的9999端口上，remote2算是中间跳板服务器，对remote1来说看到的就是remote2对remote1的访问，实际这个访问是由localhost发起的,当然这里的remote2也可以是remote1本身，即remote1充当了这个转发者

-R 参数

1

ssh -R remote:8787:localhost:3000 user@remote

此命令可以将对remote的8787端口的访问转发到本机3000端口上，这其实就是一个反向代理，让内网服务可以被remote所在的网段的其他机器所访问（如果remote是运行在公网之上，local的服务可以被公网访问

-D 参数

1

ssh -D 127.0.0.1:9999 user@remote

此命令可以开启一个TCP代理，其端口号就是9999，当其他程序使用该代理地址时，即可代理其他程序的TCP访问请求

这是第一篇，来个：你好，世界！