Web

概述 Cypress 和 Playwright 是目前最主流的两个 E2E（端到端）测试框架。两者都能模拟真实用户操作来测试 Web 应用，但在架构、能力和适用场景上有明显差异。 核心对比 维度 Cypress Playwright 开发商 Cypress.io Microsoft 首发年份 2017 2020 语言支持 JS / TS JS / TS / Python / Java / C# 浏览器支持 Chrome、Firefox、Edge、Electron Chrome、Firefox、Safari (WebKit)、Edge 移动端浏览器 不支持 支持（模拟移动设备） 多标签页 有限支持 原生支持 iframe 支持 受限 完整支持 并发执行 收费云服务 / 第三方插件 内置，免费 API 测试 支持 支持（更完整） 组件测试 成熟 实验性 架构差异 Cypress Cypress 运行在浏览器内部，测试代码与应用代码共享同一个 JavaScript 运行时。这一设计带来了极低的延迟和实时调试能力，但也造成了一些限制： 历史上不支持跨域（cross-origin）场景（v12 起已大幅改善） 同一时间只能操作一个标签页 不支持 Safari / WebKit Playwright Playwright 运行在浏览器外部，通过 Chrome DevTools Protocol（Chrome/Edge）和各浏览器原生协议（Firefox、WebKit）远程控制浏览器。这种架构更接近真实用户操作，且： ...

vue basic Vue 3 npm init vue@latest 构建工具链 Vue 3 官方脚手架从 Vue CLI（基于 Webpack）切换到了 Vite。 工具分层 层次 Vue CLI 时代 Vite 时代 工具链 Vue CLI + Webpack Vite 转译器 Babel esbuild 打包器 Webpack Rollup（生产） 压缩 Terser esbuild（默认） Babel vs esbuild 两者都是 JS 转译器（Transpiler），核心职责相同：把现代 JS/TS/JSX 语法转换成目标环境能运行的 JS。 Babel esbuild 实现语言 JavaScript Go 速度 慢 快 10-100x 可扩展性 插件生态极其丰富 插件有限 功能边界 只转译 转译 + 打包都能做 适合场景 需要复杂插件、polyfill 追求速度的现代项目 Rollup Rollup 是一个 JS 模块打包器（Bundler），解决的核心问题是：把多个 JS 模块文件合并成一个（或少数几个）输出文件。 ...

解决的问题 1. 离线体验 传统 Web 应用断网即不可用。Service Worker 可拦截网络请求，从缓存中返回资源，让应用在无网络时仍能运行。 2. 网络性能 可缓存静态资源（HTML、CSS、JS、图片），后续请求直接走缓存，减少网络延迟，加快页面加载速度。 3. 推送通知（Push Notifications） 即使页面未打开，Service Worker 也能在后台接收服务器推送的消息并展示通知。 4. 后台同步（Background Sync） 当用户在离线状态下提交表单或操作时，Service Worker 可在网络恢复后自动重试，保证数据最终被发送到服务器。 5. 独立于页面生命周期 它是独立于页面的后台进程，页面关闭后仍可运行，适合处理跨页面共享的复杂逻辑。 核心本质：Service Worker 是一个可编程的网络代理，让开发者能完全控制"请求如何被响应"，这是 Web 平台此前缺失的能力。 概述 Service Worker 是浏览器在后台独立于网页运行的脚本，本质上充当 Web 应用程序、浏览器与网络之间的代理服务器。 是一种 JavaScript Worker，无法直接访问 DOM 通过响应 postMessage 接口发送的消息与页面通信 不用时会被中止，下次有需要时重启——不能依赖全局状态，持久数据应使用 IndexedDB 广泛使用 Promise 是浏览器中的独立进程（非内核线程），注册后可被多个页面共用，页面关闭后不会销毁 Chrome 调试 chrome://inspect/#service-workers chrome://serviceworker-internals 参考 https://juejin.im/post/6844903613270081543

HTTP status, HTTP code 204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 300 Multiple Choices 多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。 301 Moved Permanently， 301 redirect: 301 代表永久性转移(Permanently Moved)。 302 redirect: 302 代表暂时性转移(Temporarily Moved )。 499 客户端主动断开连接。 504 Gateway Timeout 301 (永久移动) Permanently Moved 请求的网页已永久移动到新位置。服务器返回此响应 (对 GET 或 HEAD 请求的响应) 时，会自动将请求者转到新位置。您应使用此代码告诉 Googlebot 某个网页或网站已永久移动到新位置。 302 (临时移动) redirect, Temporarily Moved 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来响应以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置，但您不应使用此代码来告诉 Googlebot 某个网页或网站已经移动，因为 Googlebot 会继续抓取原有位置并编制索引。 304 Not Modified (未修改) 未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求 (一般是提供 If-Modified-Since 头表示客户只想比指定日期更新的文档) 。 服务器告诉客户，原来缓冲的文档还可以继续使用。 ...

Cookie Http Cookies 中 Max-age 和 Expires 有什么区别 快速回答 Expires 为 Cookie 的删除设置一个过期的日期 Max-age 设置一个 Cookie 将要过期的秒数 IE 浏览器(ie6、ie7 和 ie8) 不支持 max-age，所有的浏览器都支持 expires 深入一些来说明 expires 参数是当年网景公司推出 Cookies 原有的一部分。在 HTTP1.1 中，expires 被弃用并且被更加易用的 max-age 所替代。你只需说明这个 Cookie 能够存活多久就可以了，而不用像之前那样指定一个日期。设置二者中的一个，Cookie 会在它过期前一直保存，如果你一个都没有设置，这个 Cookie 将会一直存在直到你关闭浏览器，这种称之为 Session Cookie。 https://jiapan.me/2017/cookies-max-age-vs-expires/

RESTful API 设计 URI中不应包含结尾的正斜杠（/）。 域名 应该尽量将API部署在专用域名之下。 https://api.example.com 如果确定API很简单，不会有进一步扩展，可以考虑放在主域名下。 https://example.org/api/ 版本 Versioning 应该将API的版本号放入URL。 https://api.example.com/v1/ 另一种做法是，将版本号放在HTTP头信息中，但不如放入URL方便和直观。Github采用这种做法。 路径 Endpoint 路径又称"终点" endpoint，表示API的具体网址。 在RESTful架构中，每个网址代表一种资源 resource，所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的"集合" collection，所以API 中的名词也应该使用复数。 HTTP动词 对于资源的具体操作类型，由HTTP动词表示。 常用的HTTP动词有下面五个 (括号里是对应的SQL命令）。 GET (SELECT）：取出资源 (一项或多项）。 POST (CREATE）：新建一个资源。 PUT (UPDATE）：更新资源 (客户端提供改变后的完整资源）, Replace (Create or Update) 如果存在就替换, 没有就新增. 在HTTP中，PUT被定义为幂等(idempotent)的方法，POST 则不是，这是一个很重要的区别 PATCH (UPDATE）：更新资源 (客户端提供改变的属性）。 DELETE (DELETE）：删除资源。 还有两个不常用的HTTP动词 HEAD：获取资源的元数据。 OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。 状态码 (Status Codes） 服务器向用户返回的状态码和提示信息，常见的有以下一些 (方括号中是该状态码对应的HTTP动词）。 200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的 (Idempotent）。 201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。 202 Accepted - [*]：表示一个请求已经进入后台排队 (异步任务） 204 NO CONTENT - [DELETE]：用户删除数据成功。 400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。 401 Unauthorized - [*]：表示用户没有权限 (令牌、用户名、密码错误）,未登录或会话过期 (需要登录但未登录或会话过期） 403 Forbidden - [] 表示用户得到授权 (与401错误相对），但是访问是被禁止的。没有权限访问、操作 (IP受限或已登录但没权限） 404 NOT FOUND - []：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。 406 Not Acceptable - [GET]：用户请求的格式不可得 (比如用户请求JSON格式，但是只有XML格式）。 410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。 422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。 500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。 RESTful API 设计指南 作者： 阮一峰 版权声明：自由转载-非商用-非衍生-保持署名 (创意共享3.0许可证） ...

无限层级留言 mysql 邻接表 路径枚举 嵌套集 闭包表 redis https://www.phpbloger.com/article/50.html https://blog.bfw.wiki/user6/16249674164961840043.html

nuxt https://www.nuxtjs.cn/guide/installation npx create-nuxt-app foo 服务端渲染 (SSR） 服务端渲染 (Server-Side Rendering），是指由服务侧完成页面的 HTML 结构拼接的页面处理技术，发送到浏览器，然后为其绑定状态与事件，成为完全可交互页面的过程。 优势: 对SEO友好，减小了http请求次数，加速了页面初次渲染速度 缺点： 不灵活，先后端耦合度过高 SSR 常用于以下两个场景： 有 SEO 诉求，用在搜索引擎检索以及社交分享，用在前台类应用。 首屏渲染时长有要求，常用在移动端、弱网情况下。 客户端渲染 (BSR） 前端利用ajax等数据交互手段获取服务端提供的数据以后，渲染到HTML页面。 客户端运行了页面以后才进行json 优势：灵活，真正的先后端分离，方便于先后台各自更新维护后端 缺点： 对SEO不友好，增长了http请求次数，减缓了页面加载速度 什么是预渲染 服务端渲染，首先得有后端服务器 (一般是 Node.js）才可以使用，如果我没有后端服务器，也想用在上面提到的两个场景，那么推荐使用预渲染。 预渲染与服务端渲染唯一的不同点在于渲染时机，服务端渲染的时机是在用户访问时执行渲染 (即服务时渲染，数据一般是最新的），预渲染的时机是在项目构建时，当用户访问时，数据不一定是最新的 (如果数据没有实时性，则可以直接考虑预渲染）。 预渲染 (Pre Render）在构建时执行渲染，将渲染后的 HTML 片段生成静态 HTML 文件。无需使用 web 服务器实时动态编译 HTML，适用于静态站点生成。 https://umijs.org/zh-CN/docs/ssr#%E4%BB%80%E4%B9%88%E6%98%AF%E6%9C%8D%E5%8A%A1%E7%AB%AF%E6%B8%B2%E6%9F%93%EF%BC%9F yarn add echarts vue-echarts yarn add -D @vue/composition-api yarn add -D @nuxtjs/composition-api

“RESTful api” http://www.ruanyifeng.com/blog/2014/05/restful_api.html 路径 (Endpoint) 路径又称"终点" (endpoint) ，表示API的具体网址。 在RESTful架构中，每个网址代表一种资源 (resource) ，所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的"集合" (collection) ，所以API中的名词也应该使用复数。 举例来说，有一个API提供动物园 (zoo) 的信息，还包括各种动物和雇员的信息，则它的路径应该设计成下面这样。 https://api.example.com/v1/zoos https://api.example.com/v1/animals https://api.example.com/v1/employees HTTP动词 对于资源的具体操作类型，由HTTP动词表示。 常用的HTTP动词有下面五个 (括号里是对应的SQL命令) 。 GET (SELECT) : 从服务器取出资源 (一项或多项) 。 POST (CREATE) : 在服务器新建一个资源。 PUT (UPDATE) : 在服务器更新资源 (客户端提供改变后的完整资源) 。 PATCH (UPDATE) : 在服务器更新资源 (客户端提供改变的属性) 。 DELETE (DELETE) : 从服务器删除资源。 还有两个不常用的HTTP动词。 HEAD: 获取资源的元数据。 OPTIONS: 获取信息，关于资源的哪些属性是客户端可以改变的。 参数命名规范 query parameter可以采用驼峰命名法，也可以采用下划线命名的方式，推荐采用下划线命名的方式，据说后者比前者的识别度要高，其中，做前端开发基本都后后者，而做服务器接口开发基本用前者。 http://example.com/api/users/today_login 获取今天登陆的用户 http://example.com/api/users/today_login&sort=login_desc 获取今天登陆的用户、登陆时间降序排列 REST API规范 编写REST API，实际上就是编写处理HTTP请求的async函数，不过，REST请求和普通的HTTP请求有几个特殊的地方: REST请求仍然是标准的HTTP请求，但是，除了GET请求外，POST、PUT等请求的body是JSON数据格式，请求的Content-Type为application/json； REST响应返回的结果是JSON数据格式，因此，响应的Content-Type也是application/json。 REST规范定义了资源的通用访问格式，虽然它不是一个强制要求，但遵守该规范可以让人易于理解。 https://www.liaoxuefeng.com/wiki/1022910821149312/1105003357927328 https://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html

“nginx config, tls” ssl_certificate: 服务器的 SSL 证书文件的路径。该证书用于证明服务器的身份，并与客户端建立安全连接。通常，这个文件包含服务器的公钥信息。 ssl_certificate_key: 服务器证书匹配的私钥文件路径。私钥用于解密客户端传来的信息，因此必须保密并妥善保护。 ssl_trusted_certificate: 一个或多个被信任的证书颁发机构（CA）的证书文件路径。它用于验证客户端证书的真实性，尤其在启用客户端证书验证时。在大多数情况下，使用 Let’s Encrypt 证书时不需要单独指定这个文件，因为 fullchain.pem 已经包含了必要的中间证书链，通常足以满足大多数应用的验证需求。 TLS, nginx config include cat > /etc/nginx/tls.conf << EOF ssl_certificate /etc/letsencrypt/fullchain.pem; ssl_certificate_key /etc/letsencrypt/privkey.pem; ssl_protocols TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; EOF vim /etc/nginx/conf.d/default.conf # server config server { listen 443 ssl; server_name foo.wiloon.com; include /etc/nginx/tls.conf; location / { # ... } } stream pacman -Sy nginx-mainline-mod-stream 代理远程桌面 3389 的 tcp 连接 stream { upstream mstsc { server 1.2.3.4:3389; } server { listen 1082; proxy_pass mstsc; } } tls server { #ssl参数 listen 443 ssl; # 多域名配置 server_name foo.wiloon.com bar.wiloon.com; #证书文件 ssl_certificate example.com.crt; #私钥文件 ssl_certificate_key example.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; #... } 静态网站 server { listen 80; server_name localhost; #charset koi8-r; access_log /var/log/nginx/host.access.log main; error_log /var/log/nginx/error.log error; location / { root /usr/share/nginx/html; index index.html index.htm; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } } https://aotu.io/notes/2016/08/16/nginx-https/index.html ...

长选项, 短选项, short options, long options 1.Linux命令长选项"–“和短选项”-“和没有”-“选项背景： 在解释这些区别之前我们先了解一下有关linux的背景知识，这个需要大家先认真看完就会对这些区别有更深入的了解，对linux也有更深的了解： （1）Unix操作系统在操作风格上主要分为System V和BSD(目前一般采用BSD的第4个版本SVR4)，前者的代表的操作系统有Solaris操作系统，在Solaris1.X之前，Solaris采用的是BSD风格，2.x之后才投奔System V阵营。后者的代表的操作系统有FreeBSD。 （A）System V它最初由AT&T开发，曾经也被称为AT&T System V，是Unix操作系统众多版本中的一支。在1983年第一次发布，一共发行了4个System V的主要版本，System V Release4，或者称为SVR4，是最成功的版本，该版本有些风格成为一些UNIX共同特性的源头，如下表格的初始化脚本/etc/init.d。用来控制系统的启动和关闭。 （B）BSD（Berkeley Software Distribution，伯克利软件套件）是Unix的衍生系统，1970年代由伯克利加州大学（Uni Versity of California, Berkeley）开创。BSD用来代表由此派生出的各种套件集合。 （2）关于System V和BSD风格以及他们与Linux的关系： （A）System V 和BSD同出于AT＆T实验室的两个不同的部门，SystemV是一个Unix的商业化标准，BSD为Unix标准化的Berkeley风格。 （B）由于Linux是Linus Torvalds在以Unix为构架的系统上重新开发的，但仍沿用了两大Unix系统进程的风格，实事上应该确切的说Linus Torvalds只开发了kernel，而软件依然来自GNU和GPL两个组织。 目前只有Slackware是Linux发行版中唯一使用BSD风格的版本。其他的就是FreeBSD、NetBSD和OpenBSD三个著名的BSD发行版，并遵循「GPL规范」。在商业版的Unix及多数Linux发行版使用SystemV风格的init『可能有版权纠纷问题』。Linux代表的有：RedHat、Suse、MDV、MagicLinux、Debian等几乎大部分发行版。Unix代表的有AIX、IRIX、Solars、HP-UX。 2.Linux命令长选项”–“和短选项”-“和没有”-“选项的全部写法 （1）选项前有一横“-”，如“ls -a”（含义：list all,列出所有当前文件夹的文件） （2）选项前有两横“–”，如“ls –all”（含义：list all,列出所有当前文件夹的文件） （3）选项前有一横“-”，如“tar -xzvf”（tar命令用于对文件打包压缩或解压，格式为：“tar [选项] [文件]”，-xzvf是4个参数的组合体,tar命令最初的设计目的是将文件备份到磁带上(tape archive)，因而得名tar） （4）选项前没有任何横，如“tar xzvf” 3.Linux命令长选项”–“和短选项”-“和没有”-“选项的详细解释 （1）短选项（short options）:顾名思义，就是短小参数。它们通常包含一个连字号‘-’和一个字母（大写或小写字母）。例如：-s，-h等 （2）长选项（long options）：长选项，包含了两个连字号”–“和一些大小写字母组成的单词。例如：–size，–help等 （3）参数前有横的是 System V风格 （4）参数前没有横的是 BSD风格 4.Linux命令长选项”–“和短选项”-“的意义及额外备注 （1）一个程序通常会提供包括short options和long options两种参数形式的参数，例如：“ls -a"和“ls –all”等价 （2）因为短选项（short option）是可以合并的，如-sh,为了区分sh是一个选项还是两个选项s和h的组合，对于组合选项用单连字符’-’,如果是单一选项sh则要用双连字符’–’。例如：-sh表示-s和-h的组合，如果要表示为一个选项需要用长选项–sh。 （3）但是对于一些命令，它们不遵循以上的规则，例如：“find -type d -mindepth 2”和“find -name -fstype”（它们是单连字符’-‘连接一个完整单词，不符合3（1）和3（2）） ———————————————— 版权声明：本文为CSDN博主「快乐李同学(李俊德-大连理工大学)」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/wq6ylg08/article/details/88812451 ...

nginx location, root location 语法 Location 块通过指定模式来与客户端请求的URI相匹配。 Location 基本语法： 匹配 URI 类型，有四种参数可选，当然也可以不带参数。 命名 location，用@来标识，类似于定义goto语句块。 location [ = | ~ | * | ^ ] /URI { … } location @/name/ { … } location 匹配命令解释 空 location 后没有参数直接跟标准 URI， 表示前缀匹配，代表跟请求中的 URI 从头开始匹配。 = 用于标准 URI 前，要求请求字符串与其精准匹配，成功则立即处理，nginx 停止搜索其他匹配。 ^~ 用于标准 URI 前，并要求一旦匹配到就会立即处理，不再去匹配其他的正则 URI，一般用来匹配目录 ~ 用于正则 URI 前，表示 URI 包含正则表达式，区分大小写 ~* 用于正则 URI 前， 表示 URI 包含正则表达式，不区分大小写 @ @ 定义一个命名的 location，@ 定义的locaiton名字一般用在内部定向，例如error_page, try_files命令中。它的功能类似于编程中的goto。 location 匹配顺序 nginx 有两层指令来匹配请求 URI。第一个层次是 server 指令，它通过域名、ip 和端口来做第一层级匹配，当找到匹配的 server 后就进入此 server 的 location 匹配。 ...

chrome extension content script, 只能访问 dom, 不能访问页面 js 变量和函数 Injected Script, 被插入到页面里的 js 代码 chrome://extensions puzzle button: chrome extension 图标后面的拼图按钮 develop chrome extension doc https://developer.chrome.com/docs/extensions/mv3/ javascript web api: https://developer.mozilla.org/en-US/docs/Web/API chrome api: https://developer.mozilla.org/en-US/docs/Web/API html: https://web.dev/learn/html/ css: https://web.dev/learn/css/ javascript: https://developer.mozilla.org/en-US/docs/Learn/JavaScript chrome extension development overview: https://developer.chrome.com/docs/extensions/mv3/devguide/ chrome extension 的构成 The manifest, manifest.json, 唯一一个必须要存在于 extension 根目录的文件 The service worker, service worker 监听 chrome 的各种事件, 可以调用 Chrome api, 但是不能直接操作页面内容 Content scripts: content script 可以直接在页面中执行 js 代码, 可以直接操作 DOM, 还可以跟 service worker 通信 The popup and other pages crxjs, react https://crxjs.dev/vite-plugin ...

CORS, XSS, Cross Site Scripting, CSRF, Cross-site request forgery CORS, Cross-Origin Resource Sharing, 跨源资源共享, 跨域资源共享 CORS (Cross-Origin Resource Sharing，跨源资源共享) 是一种基于 HTTP 头的机制,允许服务器指示浏览器应该允许哪些源(域、协议或端口)来访问其资源。 核心概念 同源策略 (Same-Origin Policy) 同源策略是浏览器最核心的安全机制之一,用于隔离潜在的恶意文档,防止不同源的网页之间互相干扰。 默认情况下, 网页只能请求与自身同源的资源。 什么是"同源": 两个 URL 只有在以下三个部分完全相同时才被认为是同源的: 协议 (Protocol): http/https 域名 (Domain): 包括子域名 端口 (Port): 默认端口可省略 假设当前页面是: http://www.example.com:80/dir/page.html http://www.example.com/dir2/other.html ✅ 同源 协议、域名、端口相同 http://www.example.com:80/dir/inner/page.html ✅ 同源 80 是 http 默认端口 https://www.example.com/page.html ❌ 不同源 协议不同 (https vs http) http://www.example.com:8080/page.html ❌ 不同源 端口不同 (8080 vs 80) http://api.example.com/page.html ❌ 不同源 域名不同 (子域名不同) http://example.com/page.html ❌ 不同源 域名不同 (缺少 www) ...

jsdom jsdom 是一个纯粹由 JavaScript 实现的一系列 Web 标准，特别是 WHATWG 组织制定的 DOM 和 HTML 标准，用于在 Node.js 中使用。 大体上来说，该项目的目标是模拟足够的 Web 浏览器子集，以便用于测试和挖掘真实世界的 Web 应用程序。 import {JSDOM} from "jsdom" test('infoQ test', () => { const dom = new JSDOM(`<!DOCTYPE html><p>Hello world</p>`); console.log("foo test:", dom.window.document.querySelector("p").textContent); // "Hello world" }); 作者：0D0A 链接：https://juejin.cn/post/7151065517569081380 来源：稀土掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

form表单target的用法 偶然有一机会发现form表单的target的用法,可以实现当前页表单提交而不进行跳转刷新。代码如下,首页在页面里准备一form表单和一iframe Java代码 <img alt="收藏代码" src="http://vsp.iteye.com/images/icon_star.png" /> <form action="提交的action" method="post" target="theID"> ..................... </form> 提交到action后,action返回一串javascript语句 Java代码 <img alt="收藏代码" src="http://vsp.iteye.com/images/icon_star.png" /> String script = "<script>alert('ok!');</script>"; response.getOutputStream().write(script.getBytes("utf-8")); alert(‘ok’)将在当前页执行。原理是form提交后的结果在target指定的iframe里执行 而iframe将其隐藏。这样提交后的效果就和无刷新的效果一样。 http://vsp.iteye.com/blog/1570466

‘button input, type=“button” Which to use?’ http://web.archive.org/web/20110721191046/http://particletree.com/features/rediscovering-the-button-element/ http://www.peterbe.com/plog/button-tag-in-IE Here’s a page describing the differences (basically you can put html into a <button></button>) And an other page describing why people avoid <button></button> (Hint: IE6) Another IE problem when using <button />: And while we’re talking about IE, it’s got a couple of bugs related to the width of buttons. It’ll mysteriously add extra padding when you’re trying to add styles, meaning you have to add a tiny hack to get things under control. ...

解决JQuery.trim()函数ie下报错的问题 经常碰到JQuery里的trim()函数在firefox支持,但是在IE里不支持 其主要原因是写法不对,下面是错误的写法 Java代码 <img alt="收藏代码" src="http://vsp.iteye.com/images/icon_star.png" /> var content = $('#content').val(); if(content.trim() == ") alert('空'); 上面的写法在firefox下不会报错,但在ie下确会报错 正确的写法应该为 Java代码 <img alt="收藏代码" src="http://vsp.iteye.com/images/icon_star.png" /> var content = $('#content').val(); if($.trim(content) == ") alert('空'); 或者为: Java代码 <img alt="收藏代码" src="http://vsp.iteye.com/images/icon_star.png" /> var content = $('#content').val(); if(jQuery.trim(content) == ") alert('空'); http://vsp.iteye.com/blog/1262441

Nginx Nginx 是十分轻量级的 HTTP 服务器, Nginx, 它的发音为 “engine X”, 是一个高性能的 HTTP 和反向代理服务器, 同时也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由俄罗斯人 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的。Igor Sysoev 在建立的项目时,使用基于 BSD 许可。 Nginx 以事件驱动的方式编写,所以有非常好的性能,同时也是一个非常高效的反向代理、负载平衡。其拥有匹配 Lighttpd 的性能,同时还没有 Lighttpd 的内存泄漏问题,而且 Lighttpd 的 mod_proxy 也有一些问题并且很久没有更新。 现在, Igor 将源代码以类 BSD 许可证的形式发布。Nginx 因为它的稳定性、丰富的模块库、灵活的配置和低系统资源的消耗而闻名．业界一致认为它是 Apache2.2+mod_proxy_balancer 的轻量级代替者,不仅是因为响应静态页面的速度非常快,而且它的模块数量达到 Apache 的近 2/3。对 proxy 和 rewrite 模块的支持很彻底,还支持 mod_fcgi、ssl、vhosts ,适合用来做 mongrel clusters 的前端 HTTP 响应。 Nginx 具有很高的稳定性。其它 HTTP 服务器,当遇到访问的峰值, 或者有人恶意发起慢速连接时,也很可能会导致服务器物理内存耗尽频繁交换, 失去响应,只能重启服务器。例如当前 apache 一旦上到 200 个以上进程,web响应速度就明显非常缓慢了。而 Nginx 采取了分阶段资源分配技术,使得它的 CPU 与内存占用率非常低。Nginx 官方表示保持 10,000 个没有活动的连接,它只占 2.5M 内存,所以类似 DOS 这样的攻击对 Nginx 来说基本上是毫无用处的。就稳定性而言,Nginx 比 lighthttpd 更胜一筹。 ...

Nginx config, 配置, nginx.conf nginx 配置文件结构 Global: nginx 运行相关 Events: 与用户的网络连接相关 http http Global: 代理，缓存，日志，以及第三方模块的配置 server server Global: 虚拟主机相关 location: 地址定向，数据缓存，应答控制，以及第三方模块的配置 worker_processes, nginx 进程数，建议设置为等于 CPU 总核心数 worker_processes 8; worker_connections 每一个 worker 进程能并发处理 (发起) 的最大连接数 (包含所有连接数). 总连接数 = worker_processes * worker_connections events { worker_connections 20480; multi_accept on; use epoll; } max_clients = worker_processes * worker_connections; multi_accept multi_accept 告诉 nginx 收到一个新连接通知后接受尽可能多的连接。 multi_accept 可以让 nginx worker 进程尽可能多地接受请求。它的作用是让 worker 进程一次性地接受监听队列里的所有请求，然后处理。如果 multi_accept 的值设为off，那么 worker 进程必须一个一个地接受监听队列里的请求。 ...