var http = require('http');
http.createServer(function(req,res){
    res.writeHeader(200, {'Content-Type' : 'text/html ; charset=utf-8'})
    if(req.url !== '/favicon.ico'){
        console.time('test');
        var c=1,a=2,b=3;        
        res.write(show()+''+c);
        c=a+b;
        res.write('<br />')
        res.write(c+'<br />');
        console.timeEnd('test');
        res.end()        
    }
}).listen(8000)
function show(){
    var str='';
    for(var i=0;i<10000;i++){
        str+=i*i*i*i+'<br />';
    }
    return str
}
console.log('server is running at http://127.0.0.1:8000')

Les deux dernières lignes sont 1 et 5 !
Le livre dit que l'objet http.ServerResponse implémente un stream.Writable (flux inscriptible). Cependant, les flux inscriptibles sont généralement asynchrones (tels que le flux fs write, le flux zlib, le stdin du sous-processus), ce qui est parfait pour le modèle de service piloté par événements. Maintenant, ce que j'ai testé est la synchronisation res.write, ce qui signifie que ce rappel doit être exécuté avant que le prochain rappel dans la file d'attente des événements puisse être exécuté ?
function(req,res) est le rappel de l'événement ruquest, ce qui signifie que si vous traitez des dizaines de milliers de requêtes simultanées, vous devrez exécuter des dizaines de milliers de function(req,res), même s'il n'y en a pas Applications gourmandes en CPU dans function(req,res) Un peu s'ajoute. Cela ne signifie-t-il pas qu'il y aura des retards dans l'accès des utilisateurs ? Mais le nœud est très doué pour gérer des IO intensives ? Ai-je mal pensé ?

J'ai créé cette fonction show intentionnellement, car js est monothread et n'est pas doué pour gérer les activités gourmandes en CPU, donc res.write(show()+''+c) prend plus de temps et est plus beau. ? Si Si res.write est asynchrone, alors c=a+b sera exécuté en premier alors c doit être 5 ;