- 博客(190)
- 资源 (28)
- 收藏
- 关注
RSS订阅原创 PostgreSQL Schema 最佳实践：架构师的命名与组织艺术
📝 摘要 PostgreSQL 的 Schema 是重要的架构工具，可实现命名隔离、权限控制和多租户支持。本文探讨了 Schema 设计的关键决策： 核心问题：Schema 应被视为"数据库中的数据库"而非简单文件夹，解决命名冲突和服务隔离问题 设计权衡： 单 Schema 简单但权限粒度粗 多 Schema 提供更好隔离但增加查询复杂度 应用场景： 按服务拆分适合微服务架构 按租户拆分适合 SaaS 应用 决策模型：基于表数量、服务边界和多租户需求选择合适模式 Schema 设计需平
2026-03-20 20:43:27
458
原创 正则化：给模型加上“紧箍咒“-小白也能学会的AI概念
正则化是防止机器学习模型过拟合的关键技术，通过在损失函数中添加惩罚项来限制模型复杂度。主要包括L1正则化（产生稀疏解）、L2正则化（权重衰减）和Dropout（随机丢弃神经元）三种方法。其核心思想是在模型拟合能力和泛化能力之间取得平衡：通过约束模型不能"太复杂"，使其在新数据上表现更好。正则化虽然会略微增加训练误差和调参难度，但能显著提升模型的泛化性能。本质上是给模型加上"紧箍咒"，以牺牲部分训练拟合能力为代价，换取更好的预测效果。
2026-03-13 11:09:47
374
原创 优化器：走得更稳更快-小白也能学会的AI概念
深度学习优化器是改进梯度下降算法的关键组件。本文分析了优化器的演进历程：从基础SGD（易震荡收敛慢）到Momentum（引入惯性加速），再到Adam（结合动量与自适应学习率）。通过可视化对比和代码示例，揭示了各优化器的核心机制——SGD仅依赖当前梯度，Momentum积累历史梯度形成"惯性"，Adam则通过动态调整学习率实现更稳定快速的收敛。虽然复杂优化器会增大计算开销，但其在训练效率上的提升使其成为现代深度学习的标配，其中Adam凭借平衡性能与效果成为当前最主流选择。
2026-03-12 10:10:07
359
原创 学习率：迈多大的步子-小白也能学会的AI概念
摘要： 学习率是深度学习中的关键超参数，控制模型参数更新的步长。过大的学习率会导致模型在最优解附近震荡或发散，过小则使收敛速度过慢。其本质是在收敛速度与精度间权衡，需根据梯度方向动态调整步长。常见策略包括固定学习率、衰减学习率和自适应方法（如Adam）。学习率的选择直接影响模型能否高效稳定地找到最优解，需平衡步长以避免训练效率低下或无法收敛的问题。
2026-03-11 09:55:09
531
原创 梯度下降：寻找山谷的脚步-小白也能学会的AI概念
梯度下降是机器学习中最小化损失函数的核心优化算法，其本质是沿梯度反方向迭代更新参数。相比暴力搜索的高计算成本，梯度下降通过数学信息指引方向实现高效优化。主要变体包括：批量梯度下降（准确但慢）、随机梯度下降（快但有噪声）和小批量梯度下降（平衡速度与准确性）。该算法解决了大规模模型训练问题，但需权衡局部最优风险与超参数调优难度。核心公式θ=θ-η×∇L(θ)体现了"沿最陡下坡方向迈步"的优化思想，其中学习率η控制步长，∇L(θ)指示下降方向。
2026-03-11 06:00:00
386
原创 损失函数：模型的“成绩单“-小白也能学会的AI概念
摘要： 损失函数是机器学习的核心概念，用于量化模型预测与真实值的差距。它解决了模型优化的方向性问题，通过数学公式（如均方误差MSE和交叉熵）自动计算误差，使模型能够通过梯度下降等优化方法自动调整参数。损失函数的设计需考虑任务特性，不同任务需要选择不同函数（回归用MSE，分类用交叉熵）。其本质是模型的"成绩单"，通过最小化损失值指导模型学习。虽然通用损失函数可能不完全契合具体任务，但它是实现自动化训练的关键，使机器学习摆脱人工判断的局限。
2026-03-10 09:39:09
369
原创 多任务学习：一鱼多吃
多任务学习（MTL）是一种让单个模型同时学习多个相关任务的范式，通过共享表示层实现任务间的知识共享。相比独立训练多个模型，MTL能降低资源消耗并提升泛化能力。主要采用硬参数共享（共享底层网络）或软参数共享（参数相互约束）两种方式。虽然可能牺牲任务特异性并增加干扰风险，但MTL能有效解决知识孤岛问题，广泛应用于BERT预训练、人脸识别等场景。其核心思想是"一鱼多吃"——通过联合优化实现多任务协同学习。
2026-03-08 21:44:44
360
原创 迁移学习：站在巨人的肩膀上
迁移学习通过"预训练+微调"模式实现知识迁移，解决了数据稀缺问题。其核心思想是先在大规模通用数据上预训练模型获取通用特征，再针对特定任务进行微调。相比从零训练，迁移学习显著降低数据需求和计算成本，但可能面临负迁移风险。典型实现包括特征提取、全参数微调等策略，是现代深度学习的重要技术，使模型能够"站在巨人的肩膀上"快速适应新任务。
2026-03-07 19:55:35
465
原创 自监督学习：自己给自己出题
自监督学习是AI领域的重要范式，通过设计预任务从无标签数据中学习有效表示。核心思想是利用数据自身结构创造监督信号，主要有两种方法：对比学习（拉近正样本、推远负样本）和掩码重建（预测被遮部分）。这种方法解决了标签依赖问题，但可能牺牲任务相关性并增加预训练成本。典型应用包括BERT和MAE等模型，本质是让模型"自己给自己出题"进行学习。
2026-03-06 10:18:22
383
原创 半监督学习：站在巨人的肩膀上
摘要： 半监督学习通过结合少量带标签数据和大量无标签数据提升模型性能，解决标注成本高的问题。其核心思想是利用无标签数据的分布信息作为“弱监督”，主要方法包括伪标签（通过模型生成伪标签迭代训练）和一致性正则化（强制模型对扰动数据输出一致）。虽然降低了标注需求，但可能引入噪声并增加训练复杂度。与纯监督学习相比，半监督学习能以1%的标签数据逼近全监督效果，本质是通过数据分布信息放大有限标签的价值。
2026-03-05 09:07:16
379
原创 强化学习：在试错中成长的智能-小白也能学会的AI知识
强化学习作为机器学习的第三大范式，通过马尔可夫决策过程（MDP）框架解决序列决策问题。其核心在于智能体与环境的交互学习：智能体执行动作获得奖励反馈，不断调整策略以最大化长期收益。相比监督学习和无监督学习，强化学习的独特价值在于处理具有延迟后果的决策问题，但代价是样本效率低、训练不稳定。该方法突破了硬编码规则和随机决策的局限，通过"试错学习"机制，使机器能够在复杂环境中自主优化决策策略。
2026-03-04 10:49:41
409
原创 无监督学习：没有答案的探索-小白也能学会的AI知识
无监督学习是机器学习的重要范式，不依赖带标签数据，而是自主发现数据中的潜在结构和规律。主要任务包括聚类（相似数据分组）、降维（压缩高维数据）和异常检测。与监督学习不同，无监督学习不学习"X→Y"映射，而是探索"X之间的隐藏关系"。其优势在于不依赖昂贵标签数据，但代价是结果解释难度增加，学习目标不明确。核心思想是通过相似性度量和结构假设，让机器在无监督情况下自主发现数据内在组织方式，如用户分群或主题发现。
2026-02-28 15:23:44
1067
原创 监督学习：AI的第一堂课
监督学习是机器学习的基础范式，通过带标签数据训练模型学习输入输出的映射关系。其核心矛盾在于：既要教会机器学习，又提前告知了答案。从原始查表法（记忆训练数据）到现代监督学习（学习映射函数），关键突破在于实现泛化能力而非机械记忆。监督学习解决了预测问题，但依赖标注数据且成本高昂。本质是从数据中提炼"从X预测Y"的通用公式，而非简单记忆答案对。
2026-02-28 15:13:00
781
原创 YAGNI - 你不需要它：对“预测未来”的系统性戒断
YAGNI原则：对抗过度工程的软件开发智慧 YAGNI（You Aren't Gonna Need It）是极限编程的核心原则，旨在避免开发者为"未来可能的需求"编写不必要的代码。研究表明，大多数预埋的"扩展性"代码最终未被使用或需要重写。该原则提倡将成本延迟到需求明确时，最大化当前交付价值。其核心在于保持代码简单清晰、易于修改，而非预先构建复杂架构。通过权衡当前开发速度与未来重构成本，YAGNI帮助团队专注于真正有价值的功能，降低认知负荷和维护成本。记住：除非现在真
2026-02-26 06:00:00
1367
原创 OCP 开闭原则：即使是心脏移植，也不要切断血管
摘要：开闭原则（OCP）的现代实践 开闭原则要求软件"对扩展开放，对修改关闭"。2024-2025年的解读更强调组合、策略模式和插件架构，而非传统继承。核心在于识别变化点并封装在稳定接口后，使新增功能只需添加而非修改代码。典型反例是条件判断大杂烩，会导致回归测试地狱；解决方案是通过多态与依赖反转，将变化部分抽象为接口实现。虽然OCP降低了回归风险，但也增加了抽象复杂度和降低了代码直观性。关键记忆点：通过接口扩展功能（如新增Triangle类）而非修改核心逻辑（如draw_shape函数）
2026-02-25 06:00:00
1974
原创 SRP - 单一职责原则：被误解最深的架构基石
角色（Actor）”**的隔离——将服务于不同业务方（如财务、HR、运维）的代码剥离，以避免因一方需求变更而意外破坏另一方的功能（Spooky Action at a Distance）。单一职责原则（SRP）常被误读为“一个类只做一件事”，实则核心在于**“一个类应该只有一个引起它变化的原因”如果两个功能总是因为**不同人群（Actor）**的需求而变化，把它们绑在一起是便利还是定时炸弹？：看起来很简单，所有关于“员工”的代码都在一个文件里，不用跳来跳去。：财务的代码对了，但 HR 的报表数据全错了。
2026-02-25 06:00:00
2409
原创 LoD - 迪米特法则：拒绝“火车残骸”式代码
摘要： 迪米特法则（LoD）强调“最少知识原则”，核心是控制对象视野，避免与间接依赖（陌生人）交互。典型违规是“火车残骸”式调用（如a.getB().getC()），导致代码与内部结构强耦合，重构时易引发连锁崩溃。解决方案是通过委托（如a.doSomethingWithC()），让对象自行处理内部逻辑，外部仅与直接朋友交互。权衡中，LoD提升可维护性但可能引发接口膨胀，需注意区分合法链式调用（Fluent Interface）与违规行为。本质：只与直接朋友交谈，不触碰陌生人。
2026-02-24 06:00:00
753
原创 LSP 里氏替换原则：不是“长得像”就能当父子
多态的承诺是：使用父类的地方，换成子类也一定能工作。但如果我们写了一个子类，它覆盖了父类的方法却改变了预期的行为（比如父类说“飞”，子类抛出了“不会飞”的异常），那么所有信任父类的代码都会在运行时崩溃。：子类的前置条件（Preconditions）不能更强，后置条件（Postconditions）不能更弱。判断继承是否合理的标准，不是“它们在现实世界是不是父子”，而是“子类能否完全通过父类的测试用例”。如果鸟的核心定义是“会飞”，那么企鹅就不配继承。：符合常识，代码复用，企鹅自动拥有了鸟的属性。
2026-02-24 06:00:00
1057
原创 DIP 依赖倒置原则：是插座定义了插头，还是插头定义了插座？
本文深入解析依赖倒置原则（DIP）的本质与价值。DIP要求高层模块和低层模块都依赖抽象，而非具体实现，这与依赖注入（DI）有本质区别。文章通过"业务逻辑被数据库升级绑架"的案例，揭示直接实例化的弊端：系统僵化、难以测试和维护。解决方案是通过接口反转所有权关系，使业务逻辑定义标准，具体实现成为可替换的"插件"。虽然DIP提升了可测试性和灵活性，但也增加了装配复杂度并降低了代码导航直观性。最终通过"通用插座"比喻形象说明DIP的核心思想：通过抽象契约实
2026-02-23 06:00:00
760
原创 ISP 接口隔离原则：只给客人上他点的菜
接口隔离原则（ISP）主张“客户端不应被迫依赖它们不使用的方法”。在现代软件工程（2024-2025）中，这被视为微服务 API 设计和组件化开发的核心指南。它反对“胖接口（Fat Interfaces）”，提倡根据。上图展示了“胖接口”如何强迫实现类吞下它们不消化的东西。方法时，所有成百上千个实现类（包括那个老式打印机）都需要修改代码，即使它们根本不支持固件升级。来定义接口，这与“角色接口（Role Interfaces）”的概念不谋而合。依然强大（实现了多个接口），但。所有智能设备都实现这个接口。
2026-02-23 06:00:00
865
原创 CoI - 组合优于继承：解耦的艺术
继承（Inheritance）常被作为代码复用的首选手段，但它建立了父子类之间最强、最静态的耦合关系，导致“脆弱基类问题（Fragile Base Class）”。“组合优于继承（Composition over Inheritance）”主张通过组装小型的、独立的组件来构建复杂行为，将“是什么（Is-A）”的静态层级转化为“有什么（Has-A）”或“能做什么（Can-Do）”的动态能力，从而获得更高的灵活性和复用性。不再问“它是什么（Is-A）”，而是问“它有什么（Has-A）”。
2026-02-22 06:00:00
1685
原创 CQS - 命令查询分离：驯服副作用
摘要： 命令查询分离（CQS）原则将方法分为两类：**命令（Command）**改变状态但不返回值，**查询（Query）**返回值但不改变状态。其核心价值是消除副作用带来的不确定性，例如getBalance()方法不应同时扣费。典型反例是栈的pop()混合操作，CQS要求拆分为top()（查询）和remove()（命令）。虽然增加了代码量（如原子性操作需额外同步），但显著提升了可预测性，并为CQRS架构奠定基础。关键准则：查询应安全无副作用，命令需显式且专注状态变更。（149字）
2026-02-22 06:00:00
1075
原创 设计模式之访问者模式 (Visitor Pattern)
访问者模式通过双分派机制将操作与对象结构分离，解决操作频繁扩展的问题。当对象结构稳定但操作多变时（如编译器AST遍历、DOM操作），访问者模式让新增操作只需添加新的访问者类，而无需修改原有类结构。核心在于元素类的accept方法将自身类型告知访问者，实现操作委托。虽然增加了系统复杂性，但实现了操作与数据类的解耦，使两者能独立演化。典型应用场景包括多种导出格式、复杂对象遍历等需要灵活扩展操作的场景。
2026-02-21 06:00:00
1644
原创 设计模式之空对象模式 (Null Object Pattern)
空对象模式通过提供"什么都不做"的对象替代空值，消除繁琐的空值检查。它让空值成为正常业务状态，客户端无需特殊处理即可安全调用。该模式适用于空值是合理业务场景的情况，能简化代码并避免空指针异常，但可能掩盖真实错误。典型实现是为接口创建空实现类，其方法执行空操作或返回默认值，从而统一处理逻辑。核心价值在于用多态替代条件检查，提升代码流畅性，代价是可能降低错误可见性。
2026-02-21 06:00:00
1831
原创 设计模式之策略模式 (Strategy Pattern)
策略模式是一种将算法封装为可互换对象的设计模式，支持运行时灵活选择和切换。该模式通过将算法从使用代码中分离（如支付方式、排序算法等），消除条件判断，实现开闭原则。其核心结构包括策略接口、具体策略类和上下文类，客户端可动态注入不同策略。虽然会增加类数量，但显著提高了代码的可扩展性和复用性。典型应用场景包括支付系统、路由策略等需要灵活切换算法的场景。
2026-02-20 06:00:00
669
1
原创 设计模式之模板方法模式 (Template Method Pattern)
摘要：模板方法模式通过父类定义算法骨架，子类实现可变步骤来解决代码复用问题。该模式体现了"好莱坞原则"，父类控制流程，子类仅需关注差异部分。典型应用场景包括框架生命周期管理、数据处理流程等，能有效减少重复代码并保证流程一致性，但会牺牲一定灵活性并增加继承耦合。模式本质是分离算法骨架与具体实现，适用于多个类有相同流程但部分步骤不同的场景。
2026-02-20 06:00:00
644
原创 设计模式之观察者模式 (Observer Pattern)
观察者模式是一种事件驱动的设计模式，通过订阅-发布机制实现对象间的解耦。当主题对象状态变化时，自动通知所有订阅者，无需主题了解具体订阅者。该模式广泛应用于响应式系统、消息队列等场景，解决了状态变化的广播问题，但可能带来执行顺序不确定、循环通知等风险。核心在于将"主动调用"转变为"被动通知"，支持动态订阅和一对多通信。典型实现包含Subject维护订阅列表和notify广播方法，Observer只需实现update接口。观察者模式的本质是订阅-发布机制，实现状态变化的自
2026-02-19 06:00:00
813
原创 设计模式之状态模式 (State Pattern)
状态模式通过将对象状态封装为独立类，有效管理复杂的状态转换逻辑。该模式将条件判断转化为多态分发，使订单状态机、游戏角色等场景中的行为随状态变化更清晰。核心是将状态转换委托给状态类处理，避免大量if-else语句。虽然会增加类数量，但显著提升代码可维护性，符合开闭原则。适用于状态转换复杂且行为严重依赖状态的场景，是消除条件判断爆炸的经典解决方案。
2026-02-19 06:00:00
1087
原创 设计模式之中介者模式 (Mediator Pattern)
中介者模式通过引入中央协调者（如聊天室、消息队列等），将对象间复杂的多对多网状通信转化为一对多的星型结构。这种设计显著降低了系统耦合度，使新增对象只需与中介者交互，无需修改现有对象。其核心优势在于解耦对象间直接依赖、集中管理交互逻辑，但会牺牲部分通信效率并增加中介者复杂度。该模式适用于对象间交互复杂、需要灵活扩展的场景，典型应用包括即时通讯系统、MVC框架控制器等。关键实现要点是让同事对象仅依赖中介者，所有通信通过中介者转发完成。
2026-02-18 06:00:00
1155
原创 设计模式之备忘录模式 (Memento Pattern)
备忘录模式通过封装对象内部状态实现撤销/重做功能，核心思想是让对象自己创建状态快照（备忘录），外部仅负责存储而不解释内容。该模式包含三个角色：原发器（创建/恢复备忘录）、备忘录（封装状态）、负责人（保管备忘录）。其优势在于不破坏封装性的前提下保存状态，代价是增加内存开销和实现复杂度。典型应用场景包括文本编辑、游戏存档等需要状态恢复的功能。关键实现要点是备忘录对客户端不透明，只有原发器能解释其内容。
2026-02-18 06:00:00
1098
原创 设计模式之解释器模式 (Interpreter Pattern)
解释器模式通过将语法规则建模为类层次结构，实现特定领域语言的解析和执行。该模式将表达式转化为抽象语法树（AST），通过递归遍历树结构进行解释计算。其核心优势在于语法规则的可扩展性和解析与执行的分离，适用于简单的DSL场景如数学表达式、查询语言等。但该模式存在执行效率低、类数量膨胀等问题，复杂语法建议使用ANTLR等专业解析工具。典型实现包含终结符（如数字）和非终结符（如运算）表达式类，通过构建对象树完成语言解释。
2026-02-17 06:00:00
1155
原创 设计模式之迭代器模式 (Iterator Pattern)
迭代器模式通过将遍历逻辑从集合中分离，提供统一的遍历接口。它解决了集合内部结构与遍历需求的耦合问题，允许独立维护遍历状态并支持多种遍历策略。核心在于创建专门的迭代器对象，该对象可访问集合内部但对外隐藏细节，实现"受控暴露"。这种设计支持多线程同时遍历，但会带来轻微性能开销。Python的for循环和Java的Iterable接口都是其典型实现，体现了"状态分离、统一接口"的设计思想。
2026-02-17 06:00:00
1760
原创 设计模式之责任链模式 (Chain of Responsibility Pattern)
责任链模式是一种解耦请求发送者与处理者的设计模式，让多个对象都有机会处理请求。其核心思想是将处理者连成链，每个处理者自行决定是否处理或传递给下一节点，使请求在链上自动流转。典型应用包括审批流程、中间件处理等场景。该模式优势在于动态调整处理顺序、符合开闭原则，但会牺牲处理确定性并增加调试难度。实现时通过抽象处理者基类定义模板方法，客户端只需将请求发送给链头，无需关心具体处理逻辑。本质是将处理决策权从发送者转移到处理者，形成请求的自流转机制。
2026-02-16 06:00:00
1122
原创 设计模式之命令模式 (Command Pattern)
命令模式是一种将请求封装为对象的行为设计模式，实现请求与执行的解耦。它通过创建包含执行逻辑的命令对象，支持请求的存储、传递、排队和撤销功能。该模式适用于需要延迟执行、撤销操作、任务队列或日志回放的场景，如GUI操作、事务管理等。虽然会增加代码复杂度（每个命令需单独类），但提供了灵活控制请求执行的能力。核心思想是将方法调用转化为可操作的对象，使请求成为系统中的一等公民。
2026-02-16 06:00:00
796
原创 设计模式之享元模式 (Flyweight Pattern)
享元模式通过分离对象的内外状态，解决海量细粒度对象的内存问题。核心思想是共享不变的内部状态（如树种类、纹理），仅存储变化的外部状态（如位置）。该模式在文本编辑、游戏渲染等场景广泛应用，能大幅降低内存占用，但增加了状态管理复杂度。典型实现包括享元工厂管理共享对象、轻量级上下文持有外部状态。其本质是以计算换内存，适合对象数量庞大且内存受限的场景。
2026-02-15 06:00:00
1555
原创 设计模式之代理模式 (Proxy Pattern)
代理模式是一种控制对象访问的设计模式，通过引入代理层将访问控制逻辑与业务逻辑分离。与装饰器模式不同，代理专注于控制访问而非增强功能。该模式通过在访问路径上设置关卡（如权限检查、缓存、日志记录等），实现客户端透明访问。典型应用包括延迟加载、权限控制和远程调用等。虽然增加了调用开销和调试复杂度，但有效解决了代码重复和维护困难问题，是处理横切关注点的理想方案。代理的核心在于实现与真实对象相同的接口，在内部决定是否及如何访问真实对象。
2026-02-15 06:00:00
1017
原创 设计模式之装饰器模式 (Decorator Pattern)
装饰器模式是一种动态扩展对象功能的设计模式，通过嵌套包装替代继承，实现功能的灵活组合。其核心是将功能扩展从"纵向继承"转变为"横向包装"，每个装饰器持有被装饰对象并在调用前后添加行为。典型应用包括Python的@decorator语法和Java的IO流包装。该模式解决了继承导致的类爆炸问题，支持运行时动态配置，但会牺牲对象身份明确性并增加调试复杂度。适用于需要动态、可撤销添加职责且功能可任意组合的场景，体现了开闭原则的思想。
2026-02-14 06:00:00
1773
原创 设计模式之外观模式 (Facade Pattern)
在前端，React 的 Hooks 封装了复杂的生命周期管理。子系统仍然可以直接访问（外观不是强制性的）。：当需要为复杂的子系统提供一个简单的接口，或者需要将子系统分层时使用。外观不是强制性的，高级用户仍然可以直接访问子系统。不是"让每个客户端学习子系统"，而是"找一个专家封装所有细节"。系统复杂性与用户易用性的矛盾：内部子系统必然复杂，但客户端应该只需要简单的接口。：子系统的复杂性是客观存在的，但不应该暴露给每个客户端。：客户端需要了解所有子系统的细节，耦合严重。协调 coordinate。
2026-02-14 06:00:00
1414
原创 设计模式之桥接模式 (Bridge Pattern)
桥接模式是处理"多维度变化"的经典方案。在 GUI 框架（如 Java AWT、Flutter）中广泛应用，将"控件类型"与"渲染平台"两个维度分离。与适配器模式"事后补救"不同，桥接模式是"事前设计"。典型的"抽象-实现"分离场景：GUI（控件-平台）、设备驱动（设备-操作系统）、消息发送（消息-通道）。不是"圆形是一种红色图形"，而是"圆形有一个颜色属性"。（颜色）分离，通过一座"桥"（组合关系）连接，使它们可以独立变化。：继承是静态的、紧耦合的，但业务需求是多维度的、动态组合的。
2026-02-13 06:00:00
895
原创 设计模式之组合模式 (Composite Pattern)
组合模式是处理树形结构的标准方案。在文件系统、UI 组件树、组织架构等场景中广泛应用。它让"单个对象"和"对象组合"可以被一致对待，体现了"统一接口"的设计思想。：不要将与混淆。
2026-02-13 06:00:00
870
coreseek-4.1-beta.tar.gz
2016-09-15
<Python编程实战：运用设计模式、并发和程序库创建高质量程序>源码
2017-01-05
wp-super-cache 对象缓存功能修复版本(1.4.8版本)
2016-09-04
centos7 snort安装包
2016-12-03
通过metaWeblog Api发布Wordpress博客 实例代码
2016-08-20
c语言实用程序设计100例
2009-11-11
import-external-images.php 优化版
2016-09-02
cscope_maps.vim
2011-09-12
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人